NOTES ON

Software Project
Management
MCA SEMESTER 3
(As per Credit Based Semester and Grading System )

Mumbai University

Prepared by: Rizwan Shaikh

For Private circulation only

Reference Book:
Managing Information Technology Projects, 6e, Kathy Schwalbe,
Information Technology Project Management : Jack T. Marchewka

Mission MCA

INDEX
Unit1: An Overview of IT Project Management...................................................................4
1.1 What is project....................................................................................................................4
1.2 What is project Management.............................................................................................5
1.3 The role of project Manager...............................................................................................8
1.4 The project Management Profession .................................................................................9
1.5 Understanding organizations............................................................................................11
1.6 Stakeholder management.................................................................................................14
1.7 Project phases and the project life cycle...........................................................................15
Unit 2: Conceptualizing and Initializing IT project.............................................................18
2.1 Information Technology Project Methodology................................................................18
2.2 Business case....................................................................................................................24
2.3 Project selection and Approval.........................................................................................41
2.4 Project management processes......................................................................................44
2.5 Project charter..................................................................................................................47
2.6 Project Planning Framework............................................................................................53
Unit 3: Project Scope management..................................................................................58
3. 1 Scope definition and Project Scope management...........................................................58
3.2 Creating the Work Breakdown Structures........................................................................67
3.3 Scope Verification.............................................................................................................73
3.4 Scope Control...................................................................................................................75
Unit IV: Scheduling and Budgeting....................................................................................79
4.1 Developing the Project Schedule......................................................................................79
4.2 Schedule Control...............................................................................................................87
4.3 Basic Principles of Cost Management...............................................................................88
4.4 Cost Estimating.....91
4.4.1 Types of cost estimates......................................................................................91
4.4.2 Cost estimation Tools and Techniques...............................................................93
4.4.3 Cost Budgeting...................................................................................................96
4.5 Cost Control......................................................................................................................97
4.5.1 Earned Value Management................................................................................97
4.5.2Project Portfolio Management..........................................................................101
Unit V : Project Quality and Communication Management.............................................105
5.1 Tools and Techniques for Quality Control......................................................................105
5.2 Pareto Analysis................................................................................................................110
5.2.1 Statistical Sampling..........................................................................................110
5.3 Six Sigma.........................................................................................................................112
5.4 Quality.............................................................................................................................113
5.5 Control Charts and the seven Run Rule...........................................................................116
5.6 Modern Quality management.........................................................................................117
5.6.1 Juran and the importance of Top management...............................................119
5.6.2 commitment to Quality....................................................................................119
5.6.3 Crosby and Striving for Zero defects................................................................120
Mission MCA

Mission MCA

5.6.4 Ishikawa and the Fishbone Diagram................................................................121

5.6.5 Improving Information Technology Project Quality........................................124
5.6.6 The Project Communication Plan ...................................................................128
5.6.7 Reporting Performance and Progress.............................................................128
5.6.8 Information Distribution.................................................................................130
Unit 6: The Importance of Project Procurement Management........................................132
6.1 Planning Purchases and Acquisitions..............................................................................132
6.2 Planning Contracting.......................................................................................................133
6.3 Requesting Seller Responses...........................................................................................134
6.4 Selecting Sellers...............................................................................................................135
6.5 Administering the Contract.............................................................................................137
6.6 Closing the Contract .......................................................................................................139
6.7 Using Software to Assist in project Procurement Management....................................139
6.8 Out Sourcing....................................................................................................................140
6.8.1 The Beginning of the outsourcing phenomenon.............................................141
6.8.2 Types of outsourcing relationship..................................................................141
6.8.3 The realities of outsourcing..............................................................................141
6.8.4 Managing the outsourcing relationship..........................................................141
Unit 7: The Risk Management Plan................................................................................142
7.1 Introduction..................................................................................................................142
7.2 IT Project Risk Management, Planning Process............................................................144
7.3 Identify IT Project Risk...................................................................................................148
7.4 Risk Analysis and Assessment.......................................................................................155
7.5 Risk Strategies...............................................................................................................169
7.6 Risk Monitoring and Control..........................................................................................171
7.7 Risk Response and Evaluation...172
Unit VIII: Human Resource Management........................................................................174
8.1 Human Resource Planning..............................................................................................174
8.2 Acquiring the Project Team............................................................................................175
8.2.1 Resource Assignment.......................................................................................175
8.2.2 Resource Loading.............................................................................................176
8.2.3 Resource Leveling Developing the Project Team.............................................177
8.2.4 Managing the Project Team.............................................................................179
8.3 Change management......................................................................................................182
8.3.1 Dealing with Conflict & Resistance Leadership & Ethics..................................193
Unit IX :The Project Implementation Plan and Closure....................................................200
9.1 Project Implementation.................................................................................................200
9.2 Administrative Closure....................................................................................................204
9.3 Project Evaluation...........................................................................................................209
9.4 Leadership & Ethics in Projects.......................................................................................212
9.4.1Project Leadership.........................................................................................................212
9.4.2Ethics in Projects...........................................................................................................214
9.4.3 Multicultural Projects...................................................................................................217
Mission MCA

Mission MCA

Unit 1: An Overview of IT Project Management

Project management has been practiced since earlycivilization. Until the beginning of
twentieth century civil engineeringprojects were actually treated as projects and were
generallymanaged by creative architects and engineers. Projectmanagement as a discipline
was not accepted. It was in the 1950s that organizations started to systematically apply
projectmanagement tools and techniques to complex projects. As adiscipline, Project
Management developed from several fields ofapplication including construction,
engineering, and defence activity. Two forefathers of project management are
commonlyknown: Henry Gantt, called the father of planning and controltechniques who is
famous for his use of the Gantt chart as a projectmanagement tool; and Henri Fayol for his
creation of the fivemanagement functions which knowledge associated with project and
program management. The1950s marked the beginning of the modern Project
Managementera. Project management became recognized as a distinctdiscipline arising
from the management discipline.

1.1 What is project

All of us have been involved in projects, whether they be ourpersonal projects or in business
and industry. Examples of typicalprojects are for example:
Personal projects:
obtaining an MCA degree
writing a report
planning a party
planting a garden
Industrial projects:
Construction of a building
provide electricity to an industrial estate
building a bridge
designing a new airplane
Projects can be of any size and duration. They can besimple, like planning a party, or
complex like launching a spaceshuttle.
1.1.1 Project Definition
A project can be defined in many ways :
A project is a temporary endeavor undertaken to create aunique product, service, or
result. Operations, on the other hand, iswork done in organizations to sustain the business.
Projects aredifferent from operations in that they end when their objectiveshave been
reached or the project has been terminated.A project is temporary. A projects duration
might be just oneweek or it might go on for years, but every project has an end date.You
might not know that end date when the project begins, but itsthere somewhere in the
future. Projects are not the same asongoing operations, although the two have a great deal
in common.A project is an endeavor. Resources, such as people andequipment, need to do
work. The endeavor is undertaken by ateam or an organization, and therefore projects have
Mission MCA

Mission MCA

a sense ofbeing intentional, planned events. Successful projects do nothappen

spontaneously; some amount of preparation and planninghappens first.
Finally, every project creates a unique product or service.This is the deliverable for the
project and the reason, why thatproject was undertaken.

1.2 What is project Management

Project management is the application of knowledge,skills, tools and techniques to project
activities to meet the projectrequirements. The effectiveness of project management is
criticalin assuring the success of any substantial activity. Areas ofresponsibility for the
person handling the project include planning,control and implementation. A project should
be initiated with afeasibility study, where a clear definition of the goals and ultimatebenefits
need to be determined. Senior managers' support forprojects is important so as to ensure
authority and directionthroughout the project's progress and, also to ensure that the
goalsof the organization are effectively achieved in this process.
Knowledge, skills, goals and personalities are the factorsthat need to be considered within
project management. The projectmanager and his/her team should collectively possess
thenecessary and requisite interpersonal and technical skills tofacilitate control over the
various activities within the project.The stages of implementation must be articulated at
theproject planning phase. Disaggregating the stages at its early pointassists in the
successful development of the project by providing anumber of milestones that need to be
accomplished for completion.In addition to planning, the control of the evolving project is
also aprerequisite for its success. Control requires adequate monitoringand feedback
mechanisms by which senior management andproject managers can compare progress
against initial projectionsat each stage of the project.
Monitoring and feedback also enablesthe project manager to anticipate problems and
therefore take preemptiveand corrective measures for the benefit of the project Projects
normally involve the introduction of a new system ofsome kind and, in almost all cases, new
methods and ways ofdoing things. This impacts the work of others: the "users".
Userinteraction is an important factor in the success of projects and,indeed, the degree of
user involvement can influence the extent ofsupport for the project or its implementation
plan. A projectmanager is the one who is responsible for establishing acommunication in
between the project team and the user. Thus oneof the most essential quality of the project
manager is that of beinga good communicator, not just within the project team itself,
butwith the rest of the organization and outside world as well.
1.2.1 Features of projects:

Projects are often carried out by a team of people who havebeen assembled for that
specific purpose. The activities of thisteam may be co-ordinated by a project
manager.

Mission MCA

Mission MCA

Project teams may consist of people from different backgroundsand different parts
of the organisation. In some cases projectteams may consist of people from different
organisations.

Project teams may be inter-disciplinary groups and are likely tolie outside the normal
organisation hierarchies.

The project team will be responsible for delivery of the projectend product to some
sponsor within or outside the organisation.The full benefit of any project will not
become available until theproject as been completed.

1.2.2 Project Classification:

In recent years more and more activities have been tackledon a project basis. Project teams
and a project managementapproach have become common in most organisations. The
basicapproaches to project management remain the same regardless ofthe type of project
being considered. You may find it useful toconsider projects in relation to a number of
major classifications:
a) Engineering and construction
The projects are concerned with producing a clear physicaloutput, such as roads, bridges or
buildings. The requirementsof a project team are well defined in terms of skills
andbackground, as are the main procedures that have to beundergone. Most of the
problems which may confront theproject team are likely to have occurred before and
thereforetheir solution may be based upon past experiences.
b) Introduction of new systems
These projects would include computerisation projects and theintroduction of new systems
and procedures including financialsystems. The nature and constitution of a project team
mayvary with the subject of the project, as different skills may berequired and different
end-users may be involved. Majorprojects involving a systems analysis approach
mayincorporate clearly defined procedures within an organisation.
c) Responding to deadlines and change
An example of responding to a deadline is the preparation of anannual report by a specified
date. An increasing number ofprojects are concerned with designing organisational
orenvironmental changes, involving developing new products andservices.
1.2.3 Project Management Tools and techniques:
Project planning is at the heart of project management. Onecan't manage and control
project activities if there is no plan.Without a plan, it is impossible to know if the correct
activities areunderway, if the available resources are adequate or of the projectcan be
completed within the desired time. The plan becomes theroadmap that the project team
Mission MCA

Mission MCA

members use to guide them throughthe project activities. Project management tools and
techniquesassist project managers and their teams in carrying out work in allnine
knowledge areas. For example, some popular timemanagementtools and techniques include
Gantt charts, projectnetwork diagrams, and critical path analysis. Table 1.1 lists
somecommonly used tools and techniques by knowledge area.
Knowledge Area
Integration
management

Scope management

Tools & Techniques

Project selection methods, project
management
methodologies, stakeholder analyses,
project charters, project management
plans, project management software,
change requests, change control boards,
project review meetings, lessons-learned
reports
Scope statements, work breakdown
structures,
mind maps, statements of work,
requirements
analyses, scope management plans,
scope verification techniques, and scope
change controls

Cost Management

Net present value, return on investment,

payback
analyses, earned value management,
project portfolio management, cost
estimates, cost management plans, cost
baselines

Time management

Gantt charts, project network diagrams,

critical-path analyses, crashing, fast
tracking, schedule
performance measurements

Human resource
management

Human resource
management
Motivation techniques, empathic listening,
responsibility assignment matrices,
project
organizational charts, resource
histograms, team
building exercises
Quality metrics, checklists, quality control
charts,
Pareto diagrams, fishbone diagrams,
maturity models, statistical methods

Quality management

Mission MCA

Mission MCA

Risk management

Risk management plans, risk registers,

probability/impact matrices, risk rankings

Communication
management

Communications management plans,

kickoff
meetings, conflict management,
communications
media selection, status and progress
reports, virtual communications,
templates, project Web sites

Procurement
management

Make-or-buy analyses, contracts,

requests for
proposals or quotes, source selections,
supplier
evaluation matrices

1.3 The role of project Manager

The project manager is the driving force in the managementcontrol loop. This individual
seldom participates directly in theactivities that produce the end result, but rather strives to
maintain the progress and productive mutual interaction of various parties insuch a way
that overall risk of failure is reduced.A project manager is often a client representative and
has todetermine and implement the exact needs of the client, based onknowledge of the
firm he/she is representing. The ability to adapt tothe various internal procedures of the
contracting party, and to formclose links with the nominated representatives, is essential
inensuring that the key issues of cost, time, quality, and above all,client satisfaction, can be
realized.In whatever field, a successful project manager must be ableto envisage the entire
project from start to finish and to have theability to ensure that this vision is realized.When
they are appointed, project managers should be giventerms of reference that define their:

Objectives;
Responsibilities;
Limits of authority.

1.3.1 Responsibilities of a Project Manager:

The objective of every project manager is to deliver theproduct on time, within budget and
with the required quality.Although the precise responsibilities of a project manager will
varyfrom company to company and from project to project, they shouldalways include
planning and forecasting. Three additional areas ofmanagement responsibility are:

interpersonal responsibilities, which include:

- leading the project team;
- liaising with initiators, senior management and suppliers;

Mission MCA

Mission MCA

- being the 'figurehead', i.e. setting the example to theproject team and representing
the
project on formaloccasions.

informational responsibilities, which include:

- monitoring the performance of staff and the implementationof the project plan;
- disseminating information about tasks to the project team;
- disseminating information about project status to initiatorsand senior management;
- acting as the spokesman for the project team.

decisional responsibilities, which include:

- allocating resources according to the project plan, andadjusting those allocations when
circumstances dictate (i.e.the project manager has responsibility for the budget);
- negotiating with the initiator about the optimuminterpretation of contractual
obligations, with thecompany management for resources, and with projectstaff about
their tasks;
- handling disturbances to the smooth progress of the projectsuch as equipment failures
and personnel problems.

1.4 The project Management Profession

Guide to the Project Management Body of Knowledgeis a document available from the
Project Management Institute (PMI) an international,nonprofit, professional organization
with more than 55,000 members worldwide.The original document was published in 1987,
and the updated version providesa basis for identifying and describing the generally
accepted principles and practicesof project management. However, as PMBOK is quick to
point out, "generallyaccepted" does not mean these principles and practices work the same
way on eachand every project. It does mean that many people over time believe that these
principlesand practices are useful and have value. Determining what is appropriate is
theresponsibility of the team and comes from experience. (Perhaps experiences that canbe
documented and shared?)This text will use the PMBOK Guide as a foundation but will also
integrate anumber of concepts and ideas that are part of the body of knowledge that makes
upthe field of information systems. Ideally, you will then understand not only whatmany IT
project managers and organizations throughout the world think are important,but also the
language and the processes.
PMI provides a certification in project management through the ProjectManagement
Professional (PMP) certification exam. This text can also help you preparefor the PMP
certification exam. To pass, you must demonstrate a level of understandingand knowledge
about project management, satisfy education and experiencerequirements, and agree to
and adhere to a professional code of ethics.
Project Management Knowledge Areas
Mission MCA

Mission MCA

The Guide to the Project Management Body of Knowledge defines nine knowledgeareas for
understanding project management. These nine knowledge areas are illustratedin Figure 1
.6 and will be covered in more detail in later chapters.
Project Integration Management Integration focuses on coordinating theproject plan's
development, execution, and control of changes.
Project Scope Management A project's scope is the work to be completedby the project
team. Scope management provides assurance that the project's work is defined accurately
and completely and that it is completed asplanned. In addition, scope management includes
ways to ensure thatproper scope change procedures are in place.
Project Time Management Time management is important for developing,monitoring,
and managing the project's schedule. It includes identifying theproject's phases and
activities and then estimating, sequencing, and assigning resources for each activity to
ensure that the project's scope and objectives are met.
Project Cost Management Cost management assures that the project'sbudget is
developed and completed as approved.

Figure 1.6 Project Management Body of Knowledge (PMBOK)

Mission MCA

10

Mission MCA

Project Quality ManagementQuality management focuses on planning,developing, and

managing a quality environment that allows the project tomeet or exceed stakeholder
needs or expectations.
Project Human Resource ManagementPeople are the most importantresource on a
project. Human resource management focuses on creating anddeveloping the project team
as well as understanding and respondingappropriately to the behavioral side of project
management.
Project
Communications
ManagementCommunication
managemententails
communicating timely and accurate information about the project tothe project's
stakeholders.
Project Risk ManagementAll projects face a certain amount of risk.Project risk
management is concerned with identifying and respondingappropriately to risks that can
impact the project.
Project Procurement ManagementProjects often require resources (people,hardware,
software, etc.) that are outside the organization. Procurementmanagement makes certain
that these resources are acquired properly.
.

1.5 Understanding organizations

Every project must have its own management structuredefine d at the start and dismantled
at the end. The definition of themanagement roles, responsibilities, relationships
andaccountabilities and authorities provides the basis of thegovernance arrangements for
the project. Note that it is unlikelythat an existing line management structure will be
sufficient orappropriate to use as a project management organisation, exceptperhaps where
a small task is being run within a single businessunit with no external impact.A typical
organisation structure is depicted in the figure below

Mission MCA

11

Mission MCA

A well-designed organisation will involve the right peoplewith the right skills and the right
levels of authority so that, onceapproved, the project may proceed with minimal
requirements torefer outside the project organisation other than to deal withexception
situations outside authority of the projects SeniorResponsible Owner.There is not a onesize fits all model for the projectorganisation; you must design it to suit such things as a
projects:

Criticality to the business

Size/complexity
Degree of impact within the parent body
Degree of impact on external bodies (OGDs, Private Sector)
Cost
Staff resources required
Types/levels of interested parties

Designing the structure and getting people to agree to takeon roles takes time and may
require many discussions/negotiationswith management at appropriately senior levels.
1.5.1 The key roles:
1.5.1.1 Top management: (in certain circumstances/environmentsknown as Project
Sponsor(PS) or Programme Director).The management is the projects owner and champion
and isultimately accountable for delivery of the project and so must:provide leadership and
direction to other members of theProject Board and to the Project Managerensure that all
key stakeholders are committed to the projectand adequately represented in the projects
organisationstructure

ensure that budget holders and resource owners arecommitted to the project and
that the necessary funds andother resources are made available when required

Mission MCA

12

Mission MCA

ensure that project governance arrangements of appropriaterigour are put in place

brief senior stakeholders on the current and forecast statusof the project
receive, consider and act on regular frequentreports/briefings from the Project
Manager
chair meetings of the Project Board
ensure that all members of the Project Board understandtheir roles the
commitments they must make in order that therequired outcomes/benefits from
the project are achieved
ensure that the Project Manager is empowered to lead theproject on a day to day
basis
ensure that the Project Manager is aware of the limits ofher/his authority and
understands that issues outside thoselimits must be escalated to the PS at the
earliest opportunity.
negotiate with senior stakeholders to broker solutions toproject issues that are
outside the level of authority of theProject ManagerAs you can see, the PS is not just
a figurehead, it is anactive role as a key member of the project management team. If
theproject involves a number of organisations working together and/orhas a cross
cutting impact, it may require more than one person tobe the decision-making
authority. If this is the case, you may wishto set up a Project Board with the PS as
Chair.

1.5.1.2 The Project Board:

The Project Board should include:
the Top Management representing the business interests ofthe sponsoring
organisation as a whole
senior representative(s) from areas that will be impacted bythe outcome and must
adopt changes ;
senior representative(s) from the organisation(s) that willdesign, build and
implement the solution to meet thebusiness need, (Senior Supplier role).
The Project Board must jointly:
create an environment where the project can succeed indelivering the changes
necessary for the benefits to berealised
set the direction for the project and to approve keymilestones
approve the Project Initiation Document
ensure the appropriate resources required by the projectswithin the project are
made available in accordance with thelatest agreed version of the Project Plan
take decisions as necessary throughout the life of the project
give the Project Manager the authority to lead the project ona day to day
basis.Members of the Project Board should decide how they willassure themselves
that the integrity of those aspects of the projectfor which they are accountable is
being maintained.
1.5.1.3 Project Manager:

Mission MCA

13

Mission MCA

The Project Manager will be responsible on behalf of the PSfor day to day execution of the
project plan and for dealing withissues that might affect achievement of the plan. The
ProjectManager must:

prepare the Project Initiation Document(PID)

submit the PID to the Project Board for approval
submit any revised versions of the Project Plan andBusiness Case to the Project
Board for approval
monitor progress of the project and identify and take actionto deal with any
potential/actual exceptions that mightjeopardise achievement of the projects
objectives,
maintain a Risk Register/Log and actively manage risksusing resources and
approaches within limits of delegatedauthority
escalate to the Project Board recommendations for riskmitigations actions outside
the scope of delegated authoritylimits
report progress to, and take advice from, the PS at regularintervals as agreed
between PS and Project Manager duringProject Initiation
manage stakeholder relationships and communications (inaccordance with an
agreed Communications Plan);
liaise with any nominated Project Assurance staff throughoutthe project.

1.6 Stakeholder management

The importance of stakeholder management is to support anorganization in achieving its
strategic objectives by interpreting an influencing both the external and internal
environments and bycreating positive relationships with stakeholders through
theappropriate management of their expectations and agreedobjectives. Stakeholder
Management is a process and control thatmust be planned and guided by underlying
Principles.Stakeholder Management, within business or projects,prepares a strategy utilising
information (or intelligence) gatheredduring the following common processes:
Stakeholder Identification organisation/project.

Interested

parties either

internal or

external to

Stakeholder Analysis - Recognise and acknowledgestakeholder's needs, concerns, wants,

authority, commonrelationships, interfaces and align this information within the
Stakeholder Matrix.
Stakeholder Matrix - Positioning stakeholders according tothe level of influence, impact or
enhancement they mayprovide to the business or it's projects.
Stakeholder Engagement - Different to StakeholderManagement in that the engagement
does not seek todevelop the project/business requirements, solution orproblem creation, or
establishing roles and responsibilities. Itis primarily focused at getting to know and
understand eachother, at the Executive level. Engagement is the opportunityto discuss and
agree expectations of communication and,primarily, agree a set of Values and Principles
that allstakeholders will abide by.
Mission MCA

14

Mission MCA

Communicating Information - Expectations areestablished and agreed for the manner in

whichcommunications are managed between stakeholders whoreceives communications,
when, how and to what level ofdetail. Protocols may be established including security
andconfidentiality classifications.)
1.6.1 Stakeholder Agreements: A collection of agreed decisionsbetween stakeholders. This
may be the lexicon of an organisationor project, or the Values of an initiative, the objectives,
or the modelof the organisation, etc. These should be signed by key
stakeholderrepresentatives.Contemporary or modern business and project practicefavours
transparent, honest and open stakeholder managementprocesses.

1.7 Project phases and the project life cycle

The Project Life Cycle refers to a logical sequence ofactivities to accomplish the projects
goals or objectives.Regardless of scope or complexity, any project goes through aseries of
stages during its life. There is first an Initiation or Startingphase, in which the outputs and
critical success factors are defined,followed by a Planning phase, characterized by breaking
down theproject into smaller parts/tasks, an Execution phase, in which theproject plan is
executed, and lastly a Closure or Exit phase, thatmarks the completion of the project.
Project activities must begrouped into phases because by doing so, the project manager
andthe core team can efficiently plan and organize resources for eachactivity, and also
objectively measure achievement of goals andjustify their decisions to move ahead, correct,
or terminate.
It is ofgreat importance to organize project phases into industry-specificproject cycles. Why?
Not only because each industry sectorinvolves specific requirements, tasks, and procedures
when itcomes to projects, but also because different industry sectors havedifferent needs
for life cycle management methodology. And payingclose attention to such details is the
difference between doingthings well and excelling as project managers.Diverse project
management tools and methodologiesprevail in the different project cycle phases. Lets take
a closer lookat whats important in each one of these stages:
1.7.1 Project Initiation:
The initiation stage determines the nature and scope of thedevelopment. If this stage is not
performed well, it is unlikely thatthe project will be successful in meeting the businesss
needs. Thekey project controls needed here are an understanding of thebusiness
environment and making sure that all necessary controlsare incorporated into the project.
Any deficiencies should bereported and a recommendation should be made to fix them.The
initiation stage should include a plan that encompasses thefollowing areas:

Analyzing the business needs/requirements in measurablegoals.

Reviewing of the current operations.
Conceptual design of the operation of the final product.

Mission MCA

15

Mission MCA

Equipment and contracting requirements including anassessment of long lead time

items.
Financial analysis of the costs and benefits including abudget.
Stakeholder analysis, including users, and support personnelfor the project.
Project charter including costs, tasks, deliverables, andSchedule

1.7.2 Planning & Design:

After the initiation stage, the system is designed.Occasionally, a small prototype of the final
product is built andtested. Testing is generally performed by a combination of testersand
end users, and can occur after the prototype is built orconcurrently. Controls should be in
place that ensures that the finalproduct will meet the specifications of the project charter.
Theresults of the design stage should include a product design that:- Satisfies the project
sponsor (the person who is providing theproject budget), end user, and business
requirements.- Functions as it was intended.
- Can be produced within acceptable quality standards.
- Can be produced within time and budget constraints.
1.7.3 Execution & Controlling:
Monitoring and Controlling consists of those processesperformed to observe project
execution so that potential problemscan be identified in a timely manner and corrective
action can betaken, when necessary, to control the execution of the project. Thekey benefit
is that project performance is observed and measuredregularly to identify variances from
the project management plan.
Monitoring and Controlling includes:

Measuring the ongoing project activities (where we are);

Monitoring the project variables (cost, effort, scope, etc.)against the project
management plan and the projectperformance baseline (where we should be);

Mission MCA

16

Mission MCA

Identify corrective actions to address issues and risksproperly (How can we get on
track again);
Influencing the factors that could circumvent integratedchange control so only
approved changes are implementedIn multi-phase projects, the Monitoring and
Controllingprocess also provides feedback between project phases, in order
toimplement corrective or preventive actions to bring the project intocompliance
with the project management plan.Project Maintenance is an ongoing process, and it
includes:
Continuing support of end users
Correction of errors
Updates of the software over time

In this stage, auditors should pay attention to how effectivelyand quickly user problems are
resolved.Over the course of any IT project, the work scope maychange. Change is normal
and expected part of the process.Changes can be the result of necessary design
modifications,differing site conditions, material availability, client-requestedchanges, value
engineering and impacts from third parties, to namea few. Beyond executing the change in
the field, the changenormally needs to be documented to show what was
actuallydeveloped. This is referred to as Change Management. Hence, theowner usually
requires a final record to show all changes or, morespecifically, any change that modifies the
tangible portions of thefinished work. The record is made on the contract documents
usually, but not necessarily limited to, the design drawings. The endproduct of this effort is
what the industry terms as-built drawings, ormore simply, as built.When changes are
introduced to the project, the viability ofthe project has to be re-assessed. It is important
not to lose sight ofthe initial goals and targets of the projects. When the
changesaccumulate, the forecasted result may not justify the originalproposed investment
in the project.
1.7.4 Closure:
Closing includes the formal acceptance of the project andthe ending thereof. Administrative
activities include the archiving ofthe files and documenting lessons learned.This phase
consists of:
Project close: Finalize all activities across all of the processgroups to formally close the
project or a project phase.
Contract closure: Complete and settle each contract(including the resolution of any open
items) and close eachcontract applicable to the project or project phase.

Mission MCA

17

Mission MCA

Unit 2: Conceptualizing and Initializing IT project

2.1 Information Technology Project Methodology

A methodology provides a strategic-level plan for managing and controlling IT
projects.Think of a methodology as a template for initiating, planning, and developing
aninformation system. Although information systems may be different, it is the product,and
not necessarily the process, of managing the project that makes them different. Asyou can
see in Figure 2.1, the methodology recommends the phases, deliverables,processes, tools,
and knowledge areas for supporting an IT project. The key word isrecommends because
different types of projects, such as electronic commerce (EC),customer relations
management (CRM), or data warehousing applications, mayrequire different tools and
approaches.

Methodologies provide the project team with a game plan for implementing theproject and
product life cycles. The team can then focus on the tasks at hand, instead ofalways worrying
about what they are supposed to do next. In addition, a methodologyalso provides a
common language that allows the project team, project sponsor, andothers within the
organization to communicate more effectively. By standardizing amethodology throughout
Mission MCA

18

Mission MCA

the organization, management can compare differentprojects more objectively because

each project's planned and actual progress isreported the same way. Ideally, this will allow
management to make better-informedand more objective decisions with respect to which
projects get selected and whetherfunding should continue to support a particular project.A
good methodology should be flexible and adapt to the needs of the projectorganization
over time. For example, whether a structured or rapid applications development(RAD)
approach is used depends upon the project and application system.During the analysis and
design phases of the systems development life cycle, a teammay use one modeling
approach or a combination (i.e., process modeling, data modeling,or object-oriented
modeling).
The development and modeling approach used, however, depends on a numberof factors.
These factors may include the organization's experiences, the knowledgeand skill sets of the
project team, the IT and organizational infrastructure to supportthe development effort and
the application, and the nature of the project itselfthatis, the project's size, degree of
structure, development time frame, and role within theorganization. Many IS development
methodologies have been proposed, but mostfocus on the product of the development
effort. As discussed in Chapter 1, whether ornot an organization follows a formal IS
development methodology, the developmenteffort should fit within, or be part of, an
overall project management methodology.
Although many IT projects fail or experience significant challenges, a methodologycan
incorporate the experiences of and lessons learned by the project team
members.Developing and implementing an IT product then becomes more predictable
andthe likelihood of success increases. Over time, an organization's methodology
incorporatesa set of best practices that fits the organization and the projects it
undertakes.These best practices should lead to fewer wasted resources and projects that
providetrue value to the organization. The organization will find more opportunities for
competitiveadvantage as efficiency and effectiveness increase.
Phase 1: Conceptualize and Initialize
The first stage of the IT project methodology focuses on defining the overall goal ofthe
project. A project is undertaken for a specific purpose, and that purpose must be toadd
tangible value to the organization. Defining the project's goal is the mostimportant step in
the IT project methodology. As you will see, the project's goal aids indefining the project's
scope and guides decisions throughout the project life cycle. Itwill also be used at the end of
the project to evaluate the project's success.Alternatives that would allow the organization
to meet its goal must be identified.
Then, the costs and benefits, as well as feasibility and risk, of each alternative must
beanalyzed. Based upon these analyses, a specific alternative is recommended forfunding.
Finally, the project's goal and the analysis of alternatives that support thegoal are
summarized in a deliverable called the business case. Senior managementwill use the
business case during the selection process to determine whether the proposedproject
should be funded. The details of developing the project goal and businesscase will be
discussed in more detail later in this chapter.
Mission MCA

19

Mission MCA

Phase 2: Develop the Project Charter and Detailed Project Plan

The project charter is a key deliverable for the second phase of the IT project
methodology.It defines how the project will be organized and how the project alternative
thatwas recommended and approved for funding will be implemented. The project
charterprovides another opportunity to clarify the project's goal and defines the project's
objectivesin terms of scope, schedule, budget, and quality standards. In addition, the
projectcharter identifies and gives authority to a project manager to begin carrying out
theprocesses and tasks associated with the systems development life cycle (SDLC).
Theproject plan provides all the tactical details concerning who will carry out the
projectwork and when. The project charter and plan answer the following questions:
Who is the project manager?
Who is the project sponsor?
Who is on the project team?
What role does everyone associated with the project play?
What is the scope of the project?
How much will the project cost?
How long will it take to complete the project?
What resources and technology will be required?
What approach, tools, and techniques will be used to develop the information system?
What tasks or activities will be required to perform the project work?
How long will these tasks or activities take?
Who will be responsible for performing these tasks or activities?
What will the organization receive for the time, money, and resourcesinvested in this
project?
In addition, the project's scope, schedule, budget, and quality objectives aredefined in
detail. Although some may wish to combine the business case with theproject charter and
plan, the IT project methodology presented in this text recommendsthat the business case
and project charter/plan remain separate. There are anumber of reasons to justify
separation.First, much time and effort must be devoted to understanding the "big
picture."This process involves high-level strategic planning. Defining and agreeing to the
project'sgoal and making a recommendation are not easy, nor is getting agreement onwhich
projects should be funded. However, once the project's goal and recommendedstrategy are
defined and agreed to, it will help define the details of the project, that is,who does what
and when.
The focus of the conceptualize and initialize phase is todetermine whether a proposed
project should and can be done.The second reason is that the project charter and plan are
the products of tactical planning.Here, the details will define how the project's goal will be
achieved, by defining theapproach and tasks to support the SDLC. Combining strategic
planning with tactical planningcan confuse the project's goal and objectives with how they
should be achieved. Itthen becomes easy for people to fall into a trap where they worry too
much about howthey are going to get someplace when they have not even decided where
Mission MCA

20

Mission MCA

they are going!The third reason to separate the phases is time. It is better to pull the plug on
aproject with a high probability of failure or without the expected business value asearly as
possible. Why spend the time, money, and resources on developing a detailedplan for a
project that should not be undertaken? Therefore, a project should be doableand worth
doing before an organization spends resources determining how the projectshould be done.
Reviews at the end of each phase provide the decision-makingcontrols to ensure that
resources are committed appropriately.
Phase 3: Execute and Control the Project
The third phase of the IT project methodology focuses on execution and control
carryingout the project plan to deliver the IT product and managing the project'sprocesses
to achieve the project's goal. It is during this phase that the project teamuses a particular
approach and set of systems analysis and design tools for implementingthe systems
development life cycle (SDLC).In addition, the project manager must ensure that the
environment and infrastructureto support the project includes:
Acquisition of people with the appropriate skills, experience, and knowledge
The technical infrastructure for development
IS development methods and tools
A proper work environment
Scope, schedule, budget, and quality controls
A detailed risk plan
A procurement plan for vendors and suppliers
A quality management plan
A change management plan
A communications plan
A testing plan
An implementation plan
A human resources system for evaluation and rewards
Phase 4: Close Project
After the information system has been developed, tested, and installed, a formal
acceptanceshould transfer control from the project team to the client or project sponsor.
Theproject team should prepare a final project report and presentation to document and
verifythat all the project deliverables have been completed as defined in the project's scope.
Thisgives the project sponsor confidence that the project has been completed and makes
theformal approval and acceptance of the project go more smoothly.At this time, the final
cost of the project can be determined. Subsequently, theconsultant may invoice the client
for any remaining payments, or the accountingdepartment may make any final internal
charges to appropriate accounts. In addition,the project manager and team must follow a
set of processes to formally close theproject. These processes include such things as closing
all project accounts, archivingall project documents and files, and releasing project
resources.

Mission MCA

21

Mission MCA

Phase 5: Evaluate Project Success

The final phase of the methodology should focus on evaluating four areas. First,
apostmortem," or final project review, should be conducted by the project manager
andteam. This review should focus on the entire project and attempt to assess what
wentwell and what the project team could have done better. Subsequently, the
lessonslearned from the project team's experience should be documented and shared
withothers throughout the organization. In addition, the project manager and team
shouldidentify best practices that can be institutionalized throughout the organization
byincorporating them into the methodology. As a result, the methodology evolves
andbetter suits the organization's processes, culture, and people.
The second type of evaluation should take place between the project manager andthe
individual project team members. Although this performance review may bestructured in
terms of the organization's performance and merit review policies andprocedures, it is
important that each member of the team receive honest and usefulfeedback concerning his
or her performance on the project. Areas of strength andopportunities for improvement
should be identified so that plans of action can bedeveloped to help each person develop to
his or her potential.In addition, an outside third party should review the project, the project
manager, andproject team. The focus of this review should be to answer the following
questions:
What is the likelihood of the project achieving its goal?
Did the project meet its scope, schedule, budget, and quality objectives?
Did the project team deliver everything that was promised to the sponsor orclient?
Is the project sponsor or client satisfied with the project work?
Did the project manager and team follow the processes outlined in the project and system
development methodologies?
What risks or challenges did the project team face? And how well did theyhandle those
risks and challenges?
How well did the project sponsor, project team, and manager work together?If there were
any conflicts, how well were they addressed and managed?
Did the project manager and team act in a professional and ethical manner?Lastly, the
project must be evaluated in order to determine whether the project providedvalue to the
organization. The goal of the project should be defined in the firstphase of the project. In
general, the value an IT project brings to the organization maynot be clearly discernable
immediately after the project is implemented. Therefore, itmay be weeks or even months
before that value is known. However, time and resourcesshould be allocated for
determining whether the project met its intended goal or not.
IT Project Management Foundation
The box under the phases in Figure 2.1 defines the IT project management foundation.This
includes the project management processes, objectives, tools, infrastructure, andknowledge
areas that are needed to support the IT project.

Mission MCA

22

Mission MCA

Project Management Processes According to the Project Management Body ofKnowledge

(PMBOK), a process is a series of activities that produce a result. Projectmanagement
processes describe and help organize the work to be accomplished bythe project, while
product-oriented processes focus on the creation and delivery ofthe product of the project.
These management and product-oriented processes tend tooverlap and are integrated
throughout the project's life cycle. Each phase of themethodology should include the
following:
Initiating processesto start or initiate a project or phase once commitment is obtained.
Planning processesto develop and maintain a workable plan to supportthe project's
overall goal.
Executing processesto coordinate people and other resources to executethe plan.
Controlling processesto ensure proper control and reporting mechanismsare in place so
that progress can be monitored, problems identified, andappropriate actions taken when
necessary.
Closing processesto provide closure in terms of a formal acceptance thatthe project or a
project's phase has been completed satisfactorily.Project Objectives In addition to an overall
goal, a project will have several objectives.
These objectives support the overall goal and may be defined in terms of theproject's scope,
schedule, budget, and quality standards. Separately, each of theseobjectives cannot define
success; however, together they must support the project'sgoal. This relationship is
illustrated in Figure 2.2.Tools Tools support both the processes and product of the project.
These project managementtools, include tools and techniques for estimation, as well as
tools to developand manage scope, schedule, budget, and quality. Similarly, tools support
the developmentof the information system. For example, computer aided software
engineering(CASE) tools and models support the analysis and design phases of
development.Infrastructure Three infrastructures are needed to support the IT
project.These include:
An organizational infrastructureThe organizational infrastructure detemines how
projects are supported and managed within the organization.The organizational
infrastructure influences how project resources are allocated, the reporting relationships of
the project manager and the projectteam members, and the role of the project within the
organization.
A project infrastructureThe project infrastructuresupports the project team in terms of
theproject environment and the project team itself. Itincludes:
The project environmentThe physical workspace forthe team to meet and work.
Roles and responsibilities of the team membersThisdetermines the reporting
relationships, as well as theresponsibilities and authorities of the individual teammembers.

Mission MCA

23

Mission MCA

Processes and controlsProcesses and controls provide support formanaging all aspects of
the project. They ensure that the project's goaland objectives are being met.
A technical infrastructureThe technical infrastructure provides the hardwareand
software tools to support the project team. It may include such things asproject
management software, e-mail, voice mail, word processing, access tothe Internet, and so
on. The technical infrastructure allows the project teamto do its work.
Project Management Knowledge Areas The Project Management Body ofKnowledge
(PMBOK) encompasses nine areas generally accepted as having merit foreffectively
managing projects. These nine areas support both the project processesand product by
providing a foundation of knowledge for supporting projects within aparticular
organization.As an organization gains more experience with projects over time, the
lessonslearned from every project contribute to each of these nine areas. Ideally, these
lessonswill lead to an IT project management knowledge base that can be used to identify
bestpractices that adapt the IT project methodology to an organization's needs, culture,and
IT project environment. This base of knowledge can then be institutionalizedthroughout the
organization and its projects.

2.2 Business case

What Is a Business Case?
Although organizations have increasingly turned to information technology toimprove
effectiveness and levels of efficiency, many projects have been undertakenwithout a
thorough understanding of their full costs and risks. As a result, numerousIT projects have
failed to return benefits that compensate adequately for the time andresources invested.A
business case provides the first deliverable in the IT project life cycle. It providesan analysis
of the organizational value, feasibility, costs, benefits, and risks ofseveral proposed
alternatives or options. However, a business case is not a budget orthe project plan. The
purpose of a business case is to provide senior management withall the information needed
to make an informed decision as to whether a specific projectshould be funded (Schmidt
1999).For larger projects, a business case may be a large, formal document. Even forsmaller
projects, however, the process of thinking through why a particular project isbeing taken on
and how it might bring value to an organization is still useful.Because assumptions and new
Mission MCA

24

Mission MCA

information are sometimes used to make subjectivejudgments, a business case must also
document the methods and rationale usedfor quantifying the costs and benefits. Different
people who work independently todevelop a business case can use the same information,
tools, and methods, but stillcome up with different recommendations. Therefore, it is
imperative that decisionmakers who read the business case know and understand how it
was developed andhow various alternatives were evaluated.One can also think of a business
case as an investment proposal or a legal case.
Like an attorney the business case developer has a large degree of latitude to
structurearguments, select or ignore evidence, and deliver the final presentation. The
outcome depends largely on the ability to use compelling facts and logic in order to
influence anindividual or group with decision-making authority. Thus, a good IT business
caseshould be (1) thorough in detailing all possible impacts, costs, and benefits; (2) clearand
logical in comparing the cost/benefit impact of each alternative; (3) objectivethrough
including all pertinent information; and (4) systematic in terms of summarizingthe findings
(Schmidt 1999).
Developing the Business Case
The purpose of a business case is to show how an IT solution can create businessvalue.
Although IT projects can be undertaken for any number of reasons, organizationalvalue
generally focuses on improving effectiveness and/or efficiency. Forexample, an IT project
may be undertaken to:
Reduce costs
Create a new product or service
Improve customer service
Improve communication
Improve decision making
Create or strengthen relationships with suppliers, customers, or partners
Improve processes
Improve reporting capabilities
Support new legal requirements
Although these are just some of the reasons for proposing an IT project, it is up
tomanagement to evaluate, select, and fund projects on the basis of the value they bringto
the organization. Therefore, the business case must show explicitly how aninvestment in IT
will lead to an increase in business value. Figure 2.3 depicts theprocess for developing a
business case.Step 1: Select the Core Team Rather than have one person take sole
responsibilityfor developing the business case, a core team should be recruited. If
possible,developing a business case should include many of the stakeholders affected by
theproject or involved in its delivery. The core team should, therefore, include
managers,business specialists, and users who understand the requirements to be met,
aswell as IT specialists who understand the opportunities, limitations, and risks
associatedwith IT. In general, there are several advantages for having a core teamdevelop
the business case (Schmidt 1999):

Mission MCA

25

Mission MCA

CredibilityA team made up of individuals from various organizationalareas or

departments can provide access to critical expertise and information that may not be readily
accessible to others outside that particular area.Moreover, a team can provide different
points of view and provide a checkfor important items that an individual may overlook.
Alignment with organizational goalsHigher-level managers can help connect the
business case with the organization's long-term strategic plan andmission. This alignment
may be beneficial in understanding and presentinghow the expected business value of the
IT project will support the overallgoals and mission of the organization. Moreover, it may
facilitate prioritizing, legitimizing, and assigning value of the IT project to the organization's

Figure 2.3 The Process for Developing a Business Case

strategic business objectives. In other words, the business case should outlinehow the
successful completion of the proposed project will help the organizationachieve its overall
mission, goals, and objectives.
Access to the real costsCore members with certain expertise or access toimportant
information can help build more realistic estimates in areas suchas salaries, overhead,
accounting and reporting practices, training requirements, union rules and regulations, and
hiring practices.In addition, the core team that develops the business case can play a crucial
rolewhen dealing with various areas or departments within the organizational boundary.The
advantages include: OwnershipA cross-functional team can spread a sense of
ownershipfor the business case. A project that includes other areas from the outsethas a
better chance of reducing the political problems associated with
territorial domains.
AgreementIf you develop a business case in isolation, it is very likelythat you will have to
defend your assumptions and subjective judgments ina competitive or political setting.
However, if a core team develops thebusiness case, the critics may be more apt to argue the
results rather thanthe data and methods used.
Mission MCA

26

Mission MCA

Bridge buildingThe core team may serve as an effective tool for handlingcritics of the
business case. One tactic may be to include critics on the coreteam or to at least allow
recognition and consideration for their positions.This may lead to fewer surprises and
attacks later on.
Step 2. Define Measurable Organizational Value (MOV) The core team's objectiveshould be
to define the problem or opportunity and then identify several alternatives Hie
that will provide direct and measurable value to the organization. To provide real valueto an
organization, however, IT projects must align with and support the organization'sgoals,
mission, and objectives. Therefore, any recommended alternative by the coreteam must
have a clearly defined purpose and must map to the goals and strategy of theorganization.
The goal of the project then becomes the project's measure of success(Billows 1996; Smith
1999). In the IT project management methodology, the project'soverall goal and measure of
success is referred to as the project's measurable organizationalvalue (MOV). As the name
implies, the MOV must:

Be measurableMeasurement provides focus for the project team in termsof its actions.
Instead of implementing an information system, the projectteam attempts to achieve a
specific performance target. Moreover, an MOVprovides a basis for making decisions that
affect the project through itsremaining phases. Why do additional work or make decisions
that affectthe project if they do not help you achieve the MOV?
Provide value to the organizationResources and time should not bedevoted to a project
unless they provide some kind of value to the organization. Keep in mind that information
technology in itself cannot providevalue. Technology is only an enablerthat is, IT enables
organizations todo things.
Be agreed uponA clear and agreed upon MOV sets expectations for theproject
stakeholders. It is important that all project stakeholders understandand agree to the
project's MOV. It is not easy to get everyone to agree tothe project's goal so early; but it will
be well worth the time and effort inthe later stages of the project (Billows 1996).
VerifiableAt the end of the project, the MOV must be verified to determine if the project
was a success.The MOV guides all the decisions and processes for managing the IT project
andserves as a basis for evaluating the project's achievements. In other words, a
projectcannot be properly planned or evaluated unless the goal of the project is
clearlydefined and understood. An organization should not undertake projects that are
notclearly linked to its overall mission.
The IT value chain depicted in Figure 2.4 suggests that an organizational goalleads to or
defines an organizational strategy. In turn, a project's measurable organizationalvalue then
supports this organizational strategy. This mapping shows how aproject's goal aligns with an
organization's strategy and goal. At the end of the project,the project's actual achievements
can be compared to its initial MOV to determinewhether the project was successful. If the
Mission MCA

27

Mission MCA

project is a success (i.e., it either met orexceeded its MOV), then one can seeexplicitly how
that project will support theorganization.
For example, if we follow MichaelPorter's (Porter 1980; Porter 1985)competitive forces
model, one organizationalgoal may be to prevent customersfrom leaving or switching to a
competitor.Therefore, an organizationalstrategy to support this goal may beto develop tight
linkages with customers.To support this organizational

strategy and goal, the organization may consider developing a business-to-business I(B2B)
application that will allow customers to check inventory status, place orders,track
shipments, receive an invoice, pay an invoice, and receive various reports online.Will the
installation of hardware and a network mean that the B2B applicationwas a success? Will
the development and implementation of the application software?What if the project is
completed not only on time, but also within budget? A yesanswer here is only partially
correct. Although all of these achievements are important,they cannot be true measures of
a project's success.More specifically, installing hardware and a network are activities. Having
themin place is a necessary, but not sufficient, condition for success. In other words,
hardwareand software can be in place, but unless they support the organizational goal an
strategy, their mere installation does not bring much value to the organization. Onecan also
view budget and schedule in the same light. You can have a project that isfinished on time
and within budget, but unless it brings value to the organization in
terms of supporting a goal and strategy, it will not be of much use.But what if a project goes
over schedule and over budget? How will that impactthe project's value to the
organization? The answer is that it depends. A project that late and over budget certainly
can impact the project's value to the organization, butsuccess or failure really depends on
the amount of value a project will provide. Forexample, should a project that is one day late
and a dollar over budget be consideredunsuccessful? Probably not.
What about a project that is one week late and $ 1,000over budget? That depends on how
these overruns compare to the original schedule and budget. If the original schedule and
budget were two years and $ 1 million, thenmost people would agree that the schedule and
cost variation is no big deal.What's more important is the value the project brings to the
Mission MCA

28

Mission MCA

organization. A consultantfriend once told a story of a CEO who was ecstatic because an ecommerceproject the company was taking on was only one year late and only $12 million
overbudget. In this case, schedule and cost did not matter all that much because once the ecommerce site was up and running the company would make the deficit up withinsix
months. The moral of the story is that business value is the most important criteriafor IT
projects.
A project's MOV should be based on the organization's goal and strategy. Anexcellent
example of an MOV is the following statement that John F. Kennedy madeback in the 1960s,
"Our goal is to land a man on the moon and return him safely bythe end of the decade."This
simple yet powerful statement mobilized an entire nation and fueled thespace race with the
then Soviet Union. What is interesting about this statement is howclear and measurable the
goal becomes:
A human being is to land on the moonnot an unmanned spacecraft or aspacecraft with a
chimpanzee.
We will not just get a human to the moon or get that person just backhalfway. This person
must make the whole trip and come back safely.
This will all be done before 1970.What is equally interesting is that Kennedy never told
anyone how to do this. Thatwas NASA's job, not his. The goal was to beat the Soviets to the
moon, and the project'sMOV defined this explicitly.But how do we go about developing a
project's MOV? There are six basic steps.Let's follow that process using as an example a
company that would like to developand implement a business-to-consumer (B2C) electronic
commerce application that ithopes will allow it to expand its current bricks and mortar
operations.
Identify the Desired Area of Impact The first step involves identifying thedesired impact the
IT project will play in supporting the organization. One approachmight be to adapt the
criteria used by CIO magazine's Enterprise Value Awards.1 Theguidelines summarized in
Table 2.1 are used by the judges to define IT value and providea good starting point for
developing the MOV and business case. You should feelfree to adapt the e areas of impact
as needed. The important question to answer at thispoint is why are we thinking of doing
this project?In our B2C example, the project manager would meet with the project
sponsorand first determine how the idea for the project came about. Although the
reasonscould be broad and numerous (i.e., all of our competitors are doing it, it is part of
ourlong-term strategy, we think we can make a lot of money, B2C will make our
companylook hip), identifying them will provide a background for understanding how and
whydecisions are made by the sponsor's organization.
In this example, we will say that thereasons for considering this project are both strategic
and financial because thecompany wants to expand its current brick and mortar operations.
The idea is not toneatly categorize the project, but to understand the nature of the project
and how it willimpact the organization.Identify the Desired Value of the IT Project Once the
desired area of impact isidentified, the next step involves determining the desired value the
IT project willbring to the organization. This area is can be tricky, but having a process helps.
Mission MCA

29

Mission MCA

In simplestterms, we can identify the value of an IT project by providing answers to the

followingfour questions:
BetterWhat does the organization want to do better? (For example,improve quality or
increase effectiveness?)
FasterWhat does the organization want to do faster? (Increase speed,increase
efficiency, or reduce cycle times?)
CheaperWhat does the organization want to do cheaper? (Reduce costs?)
Do moreWhat does the organization want to do more than it is currently?(Growth or
expansion?2)
The key words to identifying the value an IT project will provide an organizationare better,
faster, cheaper, and do more. The first three criteriabetter, faster, andcheaperfocus on
quality, effectiveness, and efficiency, while doing more of somethingfocuses on growth. For
example, if an organization has identified increasing profitsas its desired area of impact, it
makes sense that it would like to make more money thanit currently does. Therefore, value
to this organization would be in the form of growth.On the other hand, another
organization may be faced with high inventory costs as aresult of having too much inventory
in its warehouse. The value that an IT project wouldbring to this organization would not be
from growth; it does not want to do more of whatit is currently doing. The value comes
from doing something better (e.g., improvedquality to reduce waste or rework), faster (e.g.,
fewer manufacturing bottlenecks orreduced cycle times), or even cheaper (e.g., lower overhead costs).

Mission MCA

30

Mission MCA

Develop an Appropriate Metric Once there is agreement as to the value the ITproject will
bring to the organization, the next step is to develop a metric or set of metricsthat
(1) provides the project team with a target or directive,
(2) sets expectationsamong all stakeholders, and
(3) provides a means for evaluating whether the projectis a success later on.
In general, tangible benefits to the organization are easier todefine than intangible ones;
however, this can be done with some creativity. Forexample, knowing whether profits
increased should be fairly straightforward, but customersatisfaction may require surveys or
interviews. Often evaluation requiresbenchmarking so that a before and after comparison
can be made To develop a metric, the project manager and sponsor should agree on a
specificnumber or range of numbers. When not obvious, the target metric should
indicatewhether an increase or decrease from the organization's current state is desired.
Themetrics may be expressed as dollars, percentages, or numbers. For example, an
organization that wishes to increase profits may state this as a 20 percent increase or
anincrease of $ 1 million from the last month, quarter, or fiscal year. On the other hand,
anorganization that would like to grow its customer base may set a goal of one hundrednew
customers. Therefore, the metrics to support an MOV may be one or a combinationof the
following:
Money (in dollars, euros, etc.)
Percentage (%) Numeric Value
(increase or decrease)
(increase or decrease)
(increase or decrease)
The company in our example would like to grow strategically, that is, expand itscurrent base
of operations. There are a number of relevant metrics that could be used.The question is
how will this company determine whether this project is a success.Keep in mind that the
organization will make a significant investment by the time theproject is completed. Will the
B2C application be successful when the Web site is finishedand anyone with an Internet
connection can view the site? It is important to have aworking Web site, but that alone will
not make up for the investment and subsequentmaintenance and support for keeping the
site up and running.
What about using a hitcounter so that the organization can tell how many times the B2C site
was visited?Having traffic to the Web site is also important, but people who just visit will not
keepthe company in business nor will visitors justify the investment and cost of keepingthe
B2C Web site up and running.It should now be obvious that the company must make money
from its B2C Website. Only a profit can justify the time, effort, and resources needed to
develop andsupport the application.
The questions then become how much profit and are there anyother metrics that should be
considered. Assume that management has determinedthat a 20 percent return will be
adequate for covering all expenses and for providing thedesired return. Also assume that
management is interested in developing new customers.Therefore, the company has set a
Mission MCA

31

Mission MCA

target of five hundred new customers. Why a20 percent return and five hundred new
customers? Those numbers are not developedby the project manager or project team on
their own. The 20 percent return and fivehundred new customers' metrics can only be
determined by the project sponsor. Theproject manager and project team only guide the
process.Set a Time Frame for Achieving the MOV Once you have agreement on the
targetmetrics that will provide the desired impact to the organization, the next step is to
agreeon a specific time frame. For example, a company may focus on increasing profits
orreducing costs, but the question is when will these results be achieved. Keep in mindthat
the scheduled completion of the project is not the same thing as the agreed upontime
frame for achieving the MOV. Scope, schedule, budget, and quality are projectobjectives.
The MOV is the project goal. Rarely will the installation of an informationsystem provide the
desired or expected value right away. A project with an immovabledeadline may, however,
have a specific date as part of the MOV. For example, there maybe cause for putting a
deadline date in the MOV in 01/01/10000, when all the dates incomputers, or whatever
they are using then, have to be changed once more.The project manager and sponsor
should also agree upon how and when the project'sMOV will be evaluated.
Continuing with the example, let's say that managementwould like to see a 20 percent
return and five hundred new customers within oneyear after the system goes online. But
what happens after the first year? Perhaps thecompany would like to maintain this growth
annually over the useful life of the system.There is, however, no reason why different
targets cannot be set for different timeperiods. For example, a 20 percent return and five
hundred new customers may besufficient for the first year, but these targets may change as
word spreads and more andmore people know about the B2C Web site. Therefore, the
company may establish target of a 25 percent return and one thousand new customers in
the second year, while 30 percent return with 1,500 new customers is set for the third
year. The MOV should beflexible to accommodate the expectations and needs of the project
sponsor.Verify and Get Agreement from the Project Stakeholders The next step indeveloping
the MOV is to ensure that it is accurate and realistic. In short, will the successfulcompletion
of this project provide the intended value to the organization? And isthe MOV realistic? The
development of the MOV requires a close working relationship between the project
manager and the sponsor.
The project manager's responsibilityis to guide the process, while the sponsor must identify
the value and targetmetrics. This joint responsibility may not always be easy, especially
when severalsponsors or individuals need to agree upon what will make an IT project
successful orwhat exactly will bring value to the organization. Still, it is better to spend the
timearguing and getting consensus now rather than during later phases of the project.While
the project manager is responsible for guiding the process, he or she needs tobe confident
that the MOV can be achieved. Being challenged is one thing; agreeing toan unrealistic MOV
is another. The latter can be detrimental to your career, the project team, and everyone's
morale.
Summarize the MOV in a Clear, Concise Statement or Table Once the impactand value to the
organization are verified and agreed upon by all the project stakeholders,the MOV should
be summarized in a single statement or table. Summarizingthe MOV
(1) provides an important chance to get final agreement and verification,
Mission MCA

32

Mission MCA

(2)provides a simple and clear directive for the project team, and
(3) sets explicit expectationsfor all project stakeholders. The easiest way to summarize the
MOV in a statementform is to complete the following statement:
This project will be successful if __________________________ .
For example, using a single statement format, the MOV would be:MOV: The B2C project will
provide a 20 percent return on investment andfive hundred new customers within the first
year of its operation.However, if the MOV includes a growth component, a table format
may be clearer. Forexample, the project's MOV over three years could be summarized as
shown in Table 2.2.Notice that the MOV does not include any explicit statements about
technology.
Morespecifically, it does not mention that a particular relational database vendor's
productwill be used or that the system will be programmed in a particular language. It is up
tothe project team to figure out how to build the system and determine what
technologywill be employed to achieve the project goal. At this point in the project, we
areconcerned with the organizationnot with the technology!The project team's directive
will be to achieve the MOV, not just develop andimplement a B2C Web site. Although
information technology will play an importantrole, the designers and developers of the
information system cannot be expected toknow everything or be solely responsible for
achieving the project goal.In the past, purely technical approaches were often applied to
organizational problems. Asystem would be built, but did it really support or have a
significant, positive impact onthe organization?
Judging from the Chaos study, most IT projects have not lived up tomanagement's
expectations. In short, the technical people may understand and be verygood at working
with the technology, but achieving this MOV will alsorequire an organizational approach and
commitment. A cross-functionalproject team that includes a number of non-technical
experts will berequired so that the burden of achieving this MOV does not rest squarely
onthe shoulders of the technical experts. Therefore, the selection of the projectteam
becomes a crucial project management decision.
Step 3: Identify Alternatives Since no single solution generally existsfor most organizational
problems, it is imperative to identify severalalternatives before dealing directly with a given
business opportunity.The alternatives, or options, identified in the business case should
bestrategies for achieving the MOV.

Mission MCA

33

Mission MCA

It is also important that the alternatives listed include a wide range of potentialsolutions as
well as a base case alternative that describes how the organizationwould perform if it
maintained the status quoi.e., if it did not pursue any of theoptions described in the
business case. In some situations, maintaining the statusquo may be the best alternative. It
is important to be open to and objective on allviable options.The base case should also
delve into the realistic costs of maintaining the currentsystem over time. Include such things
as increased maintenance costs of hardware andsoftware, as well as the possibility for more
frequent system failures and downtime.However, if the demand for service decreases,
maintaining a legacy system may be amore viable alternative than a proposed new
system.On the other hand, other options may provide the best solution. These
optionsshould consider a spectrum of choices that include:
Changing the existing business processes without investing in IT
Adopting or adapting an application developed by a different area ordepartment within
the organization
Reengineering the existing system
Purchasing an off-the-shelf application package from a software vendor
Custom building a new application using internal resources or outsourcingthe
development to another company
Step 4: Define Feasibility and Assess Risk Each option or alternative must be analyzedin
terms of its feasibility and potential risk. Feasibility should focus on whethera particular
alternative is doable and worth doing. Risk, on the other hand, focuses onwhat can go
wrong and what must go right. Analyzing the feasibility and risk of eachalternative at this
point may act as a screening process for ruling out any alternativesthat are not worth
pursuing. Feasibility may be viewed in terms of:
Economic feasibilityAlthough a cost/benefit analysis will be conducted tolook at the
alternatives in greater depth, some alternatives may be toocostly or simply not provide the
Mission MCA

34

Mission MCA

benefits envisioned in the problem statement. At this point, an organization may evaluate
an alternative in terms ofwhether funds and resources exist to support the project. For
example,although you may be in a market for a new car, the reality of your limitedincome
rules out the fancy sports car. Conducting an economic feasibilityshould serve as a reality
check for each option or alternative.
Technical feasibilityTechnical feasibility focuses on the existing technicalinfrastructure
needed to support the IT solution. Will the current infrastructure support the alternative?
Will new technology be needed? Will it beavailable? Does the current IT staff have the skills
and experience to support the proposed solution? If outsourcing, does the vendor or
companyhave the skills and experience to develop and implement the application?
Organizational feasibilityOrganizational feasibility considers theimpact on the
organization. It focuses mainly on how people within theorganization will adapt to this
planned organizational change. How willpeople and the way they do their jobs be impacted?
Will they accept thischange willingly? Will business be disrupted while the proposed
solutionis implemented?
Other feasibilitiesDepending on the situation and the organization, abusiness case may
include other issues, such as legal and ethical feasibility.Risk should focus on:
IdentificationWhat can go wrong? What must go right?
AssessmentWhat is the impact of each risk?
ResponseHow can the organization avoid or minimize the risk?
Step 5: Define Total Cost of Ownership The decision to invest in an IT projectmust take into
account all of the costs associated with the application system. TotalCost of Ownership
(TCO) is a concept that has gained widespread attention in recentyears and generally refers
to the total cost of acquiring, developing, maintaining, andsupporting the application system
over its useful life. TCO includes such costs as:
Direct or up-front costsInitial purchase price of all hardware, software,and
telecommunications equipment, all development or installation costs,outside consultant
fees, etc.
Ongoing costsSalaries, training, upgrades, supplies, maintenance, etc.
Indirect costsInitial loss of productivity, time lost by users when the system is down, the
cost of auditing equipment (i.e., finding out who has whatand where), quality assurance,
and post implementation reviews.It is important to note that TCO goes beyond the original
purchase or developmentcosts. In fact, the TCO is really an organized list of all possible cost
impacts.When preparing the business case, it is also important to document all data
sources,assumptions, and methods for determining the various costs.
Step 6: Define Total Benefits of Ownership Similarly, the Total Benefits ofOwnership (TBO)
must include all of the direct, on-going, and indirect benefitsassociated with each proposed
alternative. The TBO should address the benefits of analternative over the course of its
useful life. Benefits can arise from:
Mission MCA

35

Mission MCA

Increasing high-value workFor example, a salesperson may spend lesstime on

paperwork and more time calling on customers.
Improving accuracy and efficiencyFor example, reducing errors, duplication, or the
number of steps in a process.
Improving decision-makingFor example, providing timely and accurate information.
Improving customer serviceFor example, new products or services, faster
or more reliable service, convenience, etc.Tangible benefits associated with an IT project are
relatively easy to identify andquantify. They will usually arise from direct cost savings or
avoided costs. On theother hand, intangible benefits may be easy to identify, but they are
certainly moredifficult to quantify. It is important to try and quantify all of the benefits
identified.One way to quantify intangible benefits is to link them directly to tangible
benefitsthat can be linked to efficiency gains. For example, a corporate telephone
directoryon an intranet not only improves communication, but also can cut paper, printing,
and labor costs associated with creating and distributing a paper-based telephone book.
Another way to quantify intangible benefits is to estimate the level of service. Forexample, one could
determine how much someone is willing to pay for a particularservice or compare prices of products or
services that have or do not have a particularfeature. Moreover, if an electronic data interchange (EDI)
application allows acompany to collect its accounts receivable more quickly, it can estimate the value
ofthis benefit by determining the return it could earn by investing that money.

Step 7: Analyze Alternatives Once costs and benefits have been identified, it isimportant
that all alternatives be compared with each other consistently. Understandingthe financial
and numeric tools and techniques required by financial people and seniormanagement is
critical, even for the technically savvy. Being able to communicateeffectively using their
terms and tools increases one's credibility and the chances of gettingprojects approved and
funded. There are several ways to analyze the proposed alternatives.The most common are
financial models and scoring models.Financial models focus on either profitability and/or
cash flows. Cash flow modelsfocus on the net cash, may be positive or negative, and are
calculated by subtractingthe cash outflows from the cash inflows. In general, one could view
the benefitsassociated with a particular alternative as a source of cash inflow and the costs
as thesource of outflows.
Using a tool such as an electronic spreadsheet application, onecould conduct a sensitivity
analysis to view how changes in the initial investment ornet cash flows would impact the
risk of a particular project alternative.The most commonly used cash flow models include
payback, breakeven, returnon investment, net present value, and scoring.Payback The
payback method determines how long it will take to recover theinitial investment. For
example, if a company spends $100,000 developing and implementingan application system
and then receives a net cash return of $20,000 a year,the payback period for that
investment would be:

Mission MCA

36

Mission MCA

Although the payback period is fairly straightforward to calculate and understand,it does
not consider the time value of money or cash flows beyond the paybackperiod. Still, the
payback period is useful for highlighting the risk of a particularinvestment because a riskier
investment will have a longer payback period than a lessrisky investment. Depending on the
situation and the organization's policy, net cashflow may be either before tax or after
tax.Breakeven Similar to the payback method, the breakeven method attempts todetermine
the point at which a project would begin to recoup its original investment.This method is
useful if a certain number of transactions allow the original investmentto be recovered. For
example, let's say that you would like to create a Web site to sellgolf putters that you
manufacture. If you spent $100,000 to create the site, how manygolf putters would you
have to sell to break even if you sell each putter for $30? Todetermine this point, you have
to look at the cost of selling a putter. These costs mayinclude the following:
Materials (putter head, shaft, grip, etc.) $12.00
Labor (0.5 hours at S9.00/hr) $ 4.50
Overhead (rent, insurance, utilities, taxes, etc.) $ 8.50
Total $25.00

Mission MCA

37

Mission MCA

Mission MCA

38

Mission MCA

Mission MCA

39

Mission MCA

The scores used in this example range from 0 to 10; but there is nothingsacred about this
range. One could use a scale of 0 to 100. Consistency ratherthan any particular scale is the
key.
Financial models can be biased towards the short run. Although financialmodels are
important and should be considered, they focus solely on theperiods used in discounting
cash flows. Scoring models go beyond this limitation because they allow for multi-criteria
(Meredith and Mantel 2000).
Some criteria can be reversed-scored. In our example, higher scores forcertain criteria
make sense. For instance, higher financial performancemeasures inherently have higher
scores. However, a criterion such as riskcan be reversed-scored with lower risk alternatives
having higher scores. Ifyou reverse-score any criterion, it is beneficial to note these
assumptionsconspicuously for the reader.
Past experience may help create a more realistic business case. As mentioned before,
many of the weights and scores are subjective. Instead ofrelying on guesswork, past
experience with past projects can provide guidelines and a reference for ensuring that the
selection models are relevant andrealistic. Although the business situation, technology, and
data will changeover time, the process or method of preparing a business case and
analyzing alternatives will remain much the same. Learning from past experiencecan
improve the process and product associated with business cases andthus improves the
likelihood of a project being approved and funded.
Step 8: Propose and Support the Recommendation Once the alternatives have
beenidentified and analyzed, the last step is to recommend one of the options. It
isimportant to remember that a proposed recommendation must be supported. If
theanalysis was done diligently, this recommendation should be a relatively easy task.
Mission MCA

40

Mission MCA

The business case should be formalized in a professional-looking report. Rememberthat the

quality and accuracy of your work will be a reflection on you and your organization.A
potential client or project sponsor may not give you a second chance. Figure2.5 provides a
template for developing a business case.

2.3 Project selection and Approval

The objective of the business case is to obtain approval and funding for a
proposedalternative. However, a proposed project may have to compete against several
others.The criteria for selecting a project portfolio, a set of projects that an
organizationmay fund, are very similar to the analysis and subsequent selection of the
proposedproject alternatives. Similar to portfolio theory in finance, an organization may
wish toselect a portfolio of IT projects that have varying levels of risk,
technologicalcomplexity, size, and strategic intent (McFarlan 1981; Marchewka and Keil
1995). AnIT project portfolio mainly comprised of projects with low risk or those that do not
attempt to take advantage of new technology may lead to stagnation.
The organizationmay not move ahead strategically and the IT employees may fail to grow
professionallydue to lack of challenge. On the other hand, an organization that focuses too
heavily onrisky projects employing cutting-edge technology may end up in a precarious
positionif the IT projects experience serious problems and failures. Learning from
mistakescan be useful, unless the same mistakes are repeated over and over. Thus,
anorganization should attempt to balance its IT project portfolio with projects that
havevarying degrees of risk, cutting-edge technologies, and structure.Unfortunately, as
Harold Kerzner (Kerzner 2000, 120) points out, "What a companywants to do is not always
what it can do." He contends that companies generallyhave a number of projects that they
would like to undertake, but because oflimited resources, they must prioritize and fund
projects selectively. Depending on thedemand for IT professionals or the state of the
economy, it is not always feasible tohire new employees or to have them trained in time.
The IT Project Selection Process
Although each organization's selection process is different, this section describes thegeneral
process for selecting and funding a given project. The selection process determineswhich IT
projects will be funded in a given period. This period can be for aquarter, year, or a time
frame used by the organization. In order to weed out projectsthat have little chance of
being approved, many organizations use an initial screeningprocess in which business cases
submitted for review are compared with a set of organizationalstandards that outline
minimum requirements.Projects that meet the minimum requirements are then forwarded
to adecision-making committee of senior managers who have the authority to approve
andprovide the resources needed to support the project. On rare occasions an
individualmight make such decisions, but most organizations of any size prefer to use
committees.The committee may compare several competing projects based on the costs,
benefits,and risks to projects currently under development and to those already
implemented.Projects selected should then be assigned to a project manager who selects
the projectteam and then develops a project charter and detailed plan.
Mission MCA

41

Mission MCA

The Project Selection Decision

Even though each project proposal should be evaluated in terms of its value to
theorganization, it is important to reiterate that IT projects should not be undertaken
fortechnology's sake. The decision to approve an IT project requires a number of
conditionsbe met:
The IT project must map directly to the organization's strategies and goals.
The IT project must provide measurable organizational value that can beverified at the
completion of the project.
The selection of an IT project should be based upon diversity of measuresthat include:
Tangible costs and benefits "
Intangible costs and benefits
* Various levels throughout the organization (e.g., individual, process,department, and
enterprise)
One way to select an IT project portfolio is to use the same methods that wereused and
discussed when analyzing the project alternatives in the business case.Today, however,
there are several ways to measure the expected and realized value ofIT to an organization.
One method that is becoming increasingly popular is theBalanced Scorecard approach that
was introduced by Robert S. Kaplan and DavidNorton in a 1992 Harvard Business Review
article. Instead of focusing solely on thefinancial impact of a decision, the Balanced
Scorecard approach helps balance traditionalfinancial measures with operational metrics
across four different perspectives:finance, customer satisfaction, internal business
processes, and the organization'sability to innovate and learn (Kaplan and Norton 1992;
Kaplan and Norton 1993) An organization that utilizes the Balanced Scorecard approach
must create aset of measurements, or key performance indicators, for each of the
perspectivesillustrated in Figure 2.6. In turn, these measures are used to create a report or
:scorecard for the organization that allows management to track, or keep score, of ithe
organization's performance. The four perspectives provide a balancedapproach in terms of
tangible and intangible benefits and long and short term :
objectives, as well as how each perspective's desired outcomes and drivers impact Ithe
other perspectives.
Financial perspectiveThe Balanced Scorecard approach encouragesmanagers to consider
measures other than traditional financial measures forstrategic success. Most financial
measures are useful for understanding howan organization performed in the past, and some
have likened this tosteering the ship by watching the wake. Traditional financial
measures,however, are still important and can be a cornerstone for ensuring that
anorganization's strategies are being implemented properly. Moreimportantly, the Balanced
Scorecard approach provides a means for linkingfinancial performance with customer
focused-initia-tives, internaloperations, and investments in employees and the
infrastructure to supporttheir performance. Although traditional financial measures that
includeoperating incomeROI, NPV, IRR, and so forth are still useful, manyorganizations
are now using new financial measures as well. One financialmeasure that has been receiving
Mission MCA

42

Mission MCA

a great deal of attention and scrutinyrecently is Economic Value Added (EVA). EVA is a
measurement tool todetermine if an organization is earning

more than its true cost of capital. Supporters of EVA believe it provides aclearer picture on
whether management is creating or destroying shareholderwealth. EVA is calculated by
considering the cost of debt (e.g., theinterest rate a bank would charge) and the cost of
equity (e.g., whatshareholders could earn elsewhere). Subsequently, a positive EVA
indicatesthat positive wealth has been created.
Customer perspectiveHow an organization performs in its customers'eyes largely
determines customer satisfaction. In turn, satisfied customers can mean repeat business
and referrals for new business. As aresult, measures or targets for customer satisfaction can
be linked tofinancial rewards. They create a value chain for establishing
customerfocusedinitiatives that can be linked to financial performance Customer-based
measurements may focus on areas that determine thelevel of satisfaction with the products
and services of the company andhow well those product and services are delivered.
Internal process perspectiveThe internal process perspective focuses onthe processes
both long term and short termthat an organization mustexcel at in order to achieve its
customer and financial objectives. Customersatisfaction can be achieved through improved
operational activities by the organization, which in turn leads to improved financial
performance.Therefore, internal-based measurements should focus on the efficiency
andeffectiveness of the organization's processes.
Mission MCA

43

Mission MCA

Innovation and learning perspectiveThe abilities, capabilities, and motivations of the

people within an organization determine the outcomes of theoperational activities, financial
performance, and levels of customer satisfaction within the organization. Thus, an
organization relies heavily on itspeople not only to support the other three perspectives, but
also to providecontinuous improvements in these areas. An organization's ability to
innovate and learn at the individual level is critical for supporting the organization as a
whole. Therefore, the Balanced Scorecard approach givesconsiderable support to the
importance of investing in the future by investing in people and makes investing in human
infrastructure at least asimportant as investing in technical and physical infrastructures.
Measuresfor the innovation and learning perspective may include training, certifications,
and employee satisfaction and retention.By measuring the value of an IT project across
these four areas, the scorecardapproach compels an organization's management to
consider the impact and contextof a project from an organization-wide view. It also limits
the potential for overemphasizingtraditional financial measurement at the expense of
perspectives thatinclude both tangible and intangible benefits. Still, the Balanced Scorecard
can fail for anumber of reasons (Schneiderman 1999):
The nonfinancial measurement variables are incorrectly identified as theprimary drivers
for stakeholder satisfaction.
Metrics are not properly defined.
Goals for improvements are negotiated and not based on stakeholderrequirements,
fundamental process limits, or capabilities.
No systematic way to map high-level goals with subprocess levels wherethe actual
improvement activities reside.
Reliance on trial and error as a methodology for improvement.
There is no quantitative linkage between the nonfinancial and expectedfinancial results.
The Balanced Scorecard approach is an overall performance management systemthat is
useful for selecting all projects in an organization, monitoring their progress,and then
evaluating their overall contribution. As illustrated in Figure 2.7, the MOVconcept
introduced earlier supports the Balanced Scorecard approach.The MOV can be developed
and reviewed in terms of how it supports the four
Balanced Scorecard perspectives. However, the MOV concept can also supportorganizations
that use other means of identifying a project's value to the organization.

2.4 Project management processes

Processes are an integral component of project management. They support all of
theactivities necessary to create and implement the product of the project. As described
inChapter 2, project management processes are concerned with defining and
coordinatingthe activities and controls needed to manage the project. On the other hand,
product-orientedprocesses focus on the tangible results of the project, such as the
application systemitself. The product-oriented processes require specific domain
knowledge, tools, andtechniques in order to complete the work. For example, you would
Mission MCA

44

Mission MCA

need completely differentsubject matter experts (SME), tools, and methods to build a house
than you wouldto build a spacecraft to land on Mars. As Figure 3.1 suggests, there must be a
balancebetween project management processes and product-oriented processes. An
emphasis orsole focus on the projectmanagement processes does not provide the expertise
or ability todefine the project's scope or develop a quality system. However, a more
product-orientedfocus does not provide the management or controls to ensure that the
work is completed asrequired. Therefore, a balance is needed to complete an IT project
successfully.
Project Management Process Groups
The five process groups were introduced briefly inChapter 2. As illustrated in Figure 3.2,
these processgroups overlap within and between the differentphases of the project life
cycle since the outcome ofone process group within a phase becomes the inputProductoriented processes or catalyst for a process group of the next phase.Initiating The initiating
process signals thebeginning of the project or phase. It requires anorganization to make a
commitment in terms oftime and resources. For example, the first phase ofthe IT project
methodology recommends the developmentof a business case to identify several
viablealternatives that can support a particular organization'sstrategy and goals. In short,
the time andeffort needed to develop the business case does notcome without a cost. One
can measure this cost
directly in terms of the labor cost and time spent and indirectly by the time and effort that
couldhave been devoted to some other endeavor.

Mission MCA

45

Mission MCA

Therefore, some type of organizational commitment is needed even during the

earlieststages of a project.Similarly, a business case recommendation, once approved,
becomes a project.This decision requires an even greater commitment in terms of time and
resources;however, the next phase, when the actual work on the project commences,
requires acommitment of even more time and resources. Although all phases of the
projectshould have some type of initiating process, the first phase of the IT project
methodology,conceptualize and initialize, requires the most detail and attention.Planning
Since projects are undertaken to create something of value that generallyhas not been done
before, the planning process is of critical importance.
The planningprocess should be in line with the size and complexity of the projectthat is,
larger,complex projects may require a greater planning effort than smaller, less
complexprojects. Although planning is important for each phase of the project, the
secondphase of the IT project methodology, developing the project charter and project
plan,requires the most planning activities. In addition, planning is usually an
iterativeprocess. A project manager may develop a project plan, but senior management or
theclient may not approve the scope, budget, or schedule. In addition, planning is stillmore
of an art than a science. Experience and good judgment are just as important as and
perhaps even more important to quality planning than, using the latest projectmanagement
software tool.
It is important that the project manager and project teamdevelop a realistic and useful
project plan. Supporting processes include scope planning,activity planning, resource
Mission MCA

46

Mission MCA

planning, cost estimating, schedule estimating, organizationalplanning, and procurement

planning.Executing Once the project plan has been developed and approved, it is time
toexecute the activities of the project plan or phase. The product-oriented processesplay an
important role when completing the project plan activities. For example, thetools and
methods for developing and/or implementing a system become critical forachieving the
project's end result. Supporting processes include quality assurance,risk management, team
development, and an implementation plan. Although executingprocesses are part of every
project phase, the majority of the executing processeswill occur during the execute and
control phase of the IT project methodology.Controlling The controlling process group
allows for managing and measuring theprogress towards the project's MOV and the scope,
schedule, budget, and qualityobjectives. Controls not only tell the project team when
deviations from the planoccur, but also measure progress towards the project's goal.
Supporting processesinclude scope control, change control, schedule control, budget
control, quality control and a communications plan.
The emphasis on controlling processes will occurduring the execution and control phase of
the IT project methodology.Closing The closing process group focuses on bringing a project
or project phase toa systematic and orderly completion. The project team must verify that
all deliver-ableshave been satisfactorily completed before the project sponsor accepts the
project'sproduct. In addition, the final productthe information systemmust be
integratedsuccessfully into the day-to-day operations of the organization. Closure of a
projectshould include contract closure and administrative closure. Contract closure
ensuresthat all of the deliverables and agreed upon terms of the project have been
completedand delivered so that the project can end. It allows resources to be reassigned
andsettlement or payment of any account, if applicable.
Administrative closure, on theother hand, involves documenting and archiving all project
documents. It alsoincludes evaluating the project in terms of whether it achieved its MOV.
Lesson learned should be documented and stored in a way that allows them to be
madeavailable to other project teams, present and future. Although each phase must
include closing processes, the major emphasis on closing processes will occur during the
closeproject phase of the IT project methodology.

2.5 Project charter

The project charter and baseline project plan provide a tactical plan for carrying outor
executing the IT project. More specifically, the project charter serves as an agreementor
contract between the project sponsor and project teamdocumenting theproject's MOV,
defining its infrastructure, summarizing the project plan details,defining roles and
responsibilities, showing project commitments, and explainingproject control mechanisms.
Documenting the Project's MOVAlthough the project's MOV wasincluded in the business
case, it is important that the MOV be clearlydefined and agreed upon before developing or
executing the project plan.At this point, the MOV must be cast in stone. Once agreed upon,
the MOVfor a project should not change. As you will see, the MOV drives the project
planning process and is fundamental for all project-related decisions.
Mission MCA

47

Mission MCA

Defining the Project InfrastructureThe project charter defines all of thepeople,

resources, technology, methods, project management processes, andknowledge areas that
are required to support the project. In short, the project charter will detail everything
needed to carry out the project. Moreover,this infrastructure must not only be in place, but
must also be taken intoaccount when developing the project plan. For example, knowing
who willbe on the project team and what resources will be available to them canhelp the
project manager estimate the amount of time a particular task orset of activities will
require. It makes sense that a highly skilled and experienced team member with adequate
resources should require less time tocomplete a certain task than an inexperienced person
with inadequateresources. Keep in mind, however, that you can introduce risk to your
project plan if you develop your estimates based upon the abilities of your bestpeople. If
one of these individuals should leave sometime during the project, you may have to replace
them with someone less skilled or experienced. As a result, you will either have to revise
your estimates or face thepossibility of the project exceeding its deadline.
Summarizing the Details of the Project PlanThe project charter shouldsummarize the
scope, schedule, budget, quality objectives, deliverables, andmilestones of the project. It
should serve as an important communicationtool that provides a consolidated source of
information about the projectthat can be referenced throughout the project life cycle.
Defining Roles and ResponsibilitiesThe project charter should not onlyidentify the
project sponsor, project manager, and project team, but alsowhen and how they will be
involved throughout the project life cycle. Inaddition, the project charter should specify the
lines of reporting and whowill be responsible for specific decisions.

Showing Explicit Commitment to the ProjectIn addition to defining theroles and

responsibilities of the various stakeholders, the project chartershould detail the resources to
be provided by the project sponsor and specify clearly who will take ownership of the
project's product once the project is completed. Approval of the project charter gives the
project team theformal authority to begin work on the project.
Setting Out Project Control MechanismsChanges to the project's scope,schedule, and
budget will undoubtedly be required over the course of theproject. But, the project
manager can lose control and the project team canlose its focus if these changes are not
managed properly. Therefore, theproject charter should outline a process for requesting
and responding toproposed changes.In general, the project charter and project plan should
be developed togetherthedetails of the project plan need to be summarized in the project
charter, and the infrastructureoutlined in the project charter will influence the estimates
used in developingthe project plan. It is the responsibility of the project manager to ensure
that theproject charter and plan are developed, agreed upon, and approved. Like the
businesscase, the project charter and plan should be developed with both the project team
andthe project sponsor to ensure that the project will support the organization and that
thegoal and objective of the project are realistic and achievable.
What Should Be in a Project Charter?
Mission MCA

48

Mission MCA

The framework for a project charter should be based on the nine project
managementknowledge areas and processes. Although the formality and depth of
developing aproject charter will most likely depend on the size and complexity of the
project, thefundamental project management processes and areas should be addressed
andincluded for all projects. This section presents an overview of the typical areas thatmay
go into a project charter; however, organizations and project managers shouldadapt the
project charter based on best practices, experience, and the project itself.
Project Identification It is common for all projects to have a unique name or a wayto
identify them. It is especially necessary if an organization has several projectsunderway at
once. Naming a project can also give the project team and stakeholders asense of identity
and ownership. Often organizations will use some type of acronym forthe project's name.
For example, instead of naming a project something as mundane asthe Flight Reservation
System in 1965, American Airlines named its system SABRE.Today, SABRE has become a
well-recognized product that connects travel agents andonline customers with all of the
major airlines, car rental companies, hotels,railways, and cruise lines.
Project Stakeholders It is important that the project charter specifically name theproject
sponsor and the project manager. This reduces the likelihood of confusion whendetermining
who will take ownership of the project's product and who will be the leader ofthe project. In
addition, the project team should be named along with their titles or rolesin the project,
their phone numbers, and e-mail addresses. This section should describewho will be
involved in the project, how they will be involved, and when they will beinvolved. Formal
reporting relationships can be specified and may be useful on largerprojects. In addition,
including telephone numbers and e-mail addresses can provide ahandy directory for getting
in touch with the various participants.
Project Description The project charter should be a single source of information.Therefore,
it may be useful to include a description of the project to help someone unfamiliarwith the
project understand not only the details, but the larger picture as well. Thismay include a
brief overview or background of the project as to the problem or opportunitythat became a
catalyst for the project and the reason or purpose for taking on theproject. It may also be
useful to include the vision of the organization or project and how italigns with the
organization's goal and strategy. Much of this section could summarize thetotal benefits
expected from the project that were described in the business case. It isimportant that the
project description focus on the business and not the technology.
Measurable Organizational Value (MOV) The MOV should be clear, concise,agreed upon,
and made explicit to all of the project stakeholders. Therefore, the project'sMOV should be
highlighted and easily identifiable in the project charter.
Project Scope The project's scope is the work to be completed. A specific section of
theproject charter should clarify not only what will be produced or delivered by the
projectteam, but also what will not be part of the project's scope. This distinction is
important fortwo reasons. First, it provides the foundation for developing the project plan's
scheduleand cost estimates. Changes to the project's scope will impact the project's
Mission MCA

49

Mission MCA

schedule andbudgetthat is, if resources are fixed, expanding the amount work you have to
completewill take more time and money. Therefore, the creation of additional work for the
projectteam will extend the project's schedule and invariably increase the cost of
theproject.
Formal procedures must be in place to control and manage the project's scope.Secondly, it
is important for the project manager to manage the expectations of the projectsponsor and
the project team. By making the project's scope explicit as to what is and whatis not to be
delivered, the likelihood of confusion and misunderstanding is reduced. Forexample, the
project team and several users may have several discussions regardingthe scope of a
project. One user may suggest that the system should allow for thedownload of reports to a
wireless personal digital assistant (PDA). After discussingthis idea in depth, management
may decide that the cost and time to add this wirelessPDA capability would not be in the
organization's best interest. In this case, it wouldbe a good idea to explicitly state in the
project charter that wireless PDA capabilitywill not be part of the project's scope. Although
you may be clear on this issue, othersmay still have different expectations. The project's
scope should, therefore, define keydeliverables and/or high-level descriptions of the
information system's functionality.The details of the system's features and functionality will,
however, be determinedlater in the systems development life cycle when the project team
conducts aninformation requirements analysis.
Project Schedule Although the details of the project's schedule will be in the projectplan, it is
important to summarize the detail of the plan with respect to the expectedstart and
completion dates. In addition, expected dates for major deliverables, milestones,and phases
should be highlighted and summarized at a very high level.
Project Budget A section of the project charter should highlight the total cost of theproject.
The total cost of the project should be summarized directly from the project plan.
Quality Issues Although a quality management plan should be in place to supportthe
project, a section that identifies any known or required quality standards shouldbe made
explicit in the project charter. For example, an application system's reportsmay have to
meet a government agency's requirements.
Resources Because the project charter acts as an agreement or contract, it may beuseful to
specify the resources required and who is responsible for providing thoseresources.
Resources may include people, technology, or facilities to support theproject team. It would
be somewhat awkward for a team of consultants to arrive athe client's organization and find
that the only space available for them to work is acorner table in the company cafeteria!
Therefore, explicitly outlining theresources needed and who is responsible for what can
reduce the likelihood for confusionor misunderstanding.
Assumptions and Risks Any risks or assumptions should be documented in theproject
charter. Assumptions may include things that must go right, such as a particularteam
member being available for the project, or specific criteria used in developing theproject
plan estimates. Risks, on the other hand, may be thought of as anything that cango wrong or
things that may impact the success of the project. Although a riskmanagement plan should
Mission MCA

50

Mission MCA

be in place to support the project team, the project chartershould summarize the following
potential impacts:
Key situations or events that could significantly impact the project s scope,schedule, or
budget. These risks, their likelihood, and the strategy to overcome or minimize their impact
should be detailed in the project's risk plan.
Any known constraints that may be imposed by the organization or project environment
should be documented. Known constraints may include
such things as imposed deadlines, budgets, or required technology tools orplatforms.
Dependencies on other projects internal or external to the organization. Inmost cases, an
IT project is one of several being undertaken by an organiztion. Subsequently, dependencies
between projects may exist, especially if different application systems or technology
platforms must be integrated. It mayalso be important to describe the project's role in
relation to other projects.
Impacts on different areas of the organization. As described in Chapter 1, ITprojects
operate in a broader environment than the project itself. As a result,the development and
implementation of an IT solution will have an impact on the organization. It is important to
describe how the project will impactthe organization in terms of disruption, downtime, or
loss of productivity.
Any outstanding issues. It is important to highlight any outstanding issuesthat need further
resolution. These may be issues identified by the projectsponsor, the project manager, or
the project team that must be addressedand agreed upon at some point during the project.
They may include suchthings as resources to be provided or decisions regarding the features
orfunctionality of the system.Project Administration Project administration focuses on the
controls that willsupport the project. It may include:
A communications plan that outlines how the project's status or progresswill be reported
to various stakeholders. This plan also includes a processfor reporting and resolving
significant issues or problems as they arise.
A scope management plan that describes how changes to the project'sscope will be
submitted, logged, and reviewed.
A quality management plan that details how quality planning, assurance,and control will
be supported throughout the project life cycle. In addition,a plan for testing the information
system will be included.
A change management and implementation plan that will specify how theproject's
product will be integrated into the organizational environment.
A human resources plan for staff acquisition and team development.Acceptance and
Approval Since the project charter serves as an agreement or contractbetween the project
Mission MCA

51

Mission MCA

sponsor and project team, it may be necessary to have keystakeholders sign off on the
project charter. By signing the document, the projectstakeholder shows his/her formal
acceptance of the project and, therefore, gives theproject manager and team the authority
to carry out the project plan.References In developing the project charter and plan, the
project manager may use anumber of references. It is important to document these
references in order to addcredibility to the project charter and plan, as well as to provide a
basis for supportingcertain processes, practices, or estimates.Terminology Many IT projects
use certain terms or acronyms that may be unfamiliarto many people. Therefore, to reduce
complexity and confusion, it may be useful toinclude a glossary giving the meaning of terms
and acronyms, allowing all the project'sstakeholders to use a common language. Figure 3.4
provides a template for a projectcharter. Feel free to adapt this template as needed.

Mission MCA

52

Mission MCA

2.6 Project Planning Framework

In this section, a project planning framework will be introduced. This framework ispart of
the IT project methodology and provides the steps and processes necessary todevelop the
detailed project plan that will support
support the project's MOV. A project planattempts to answer
the following questions:
What needs to be done?
Who will do the work?
When will they do the work?
How long will it take?
How much will it cost?
The project planning framework illustrated
illustrated in Figure 3.5 consists of several stepsand
processes. We will now focus on each of these steps to show how the project'sschedule and
budget are derived.

The MOV

Mission MCA

53

Mission MCA

The first step of the project planning framework entails finalizing the definition of
andagreement on the project's measurable organizational value or MOV. Although anindepth discussion of a project's MOV was provided in Chapter 2, it is importanthere to focus
on a few salient points. First, it is important that the project's MOV bedefined and agreed
upon before proceeding to the other steps of the project planningframework. The project's
MOV provides a direct link to the organization's strategicmission; however, as Figure 3.5
illustrates, a project's MOV links directly to the projectplan. Therefore, a project's MOV acts
as a bridge between the strategic mission andobjectives of the organization and the project
plans of individual projects it undertakes.The MOV guides many of the decisions related to
scope, schedule, budget, andresources throughout the project's life cycle.
Define the Project's Scope
Once the project's MOV has been defined and agreed upon by theproject's stakeholders,
the next step of the project planning framework is to define theproject's scope.The Project
Management Body of Knowledge defines scope as the product orservices to be provided by
the project and includes all of the project deliverables. Onecan think of scope as the work
that needs to be completed in order to achieve the project'sMOV.
Project scope management is one of the nine project management knowledgeareas and
entails the following processes:
InitiationOnce the project's MOV has been defined and agreed upon, theorganization
must make a commitment, in terms of time and resources, todefine the project's scope in
order to create the project plan.
PlanningThe project team must develop a written statement thatdefines the work to be
included, as well as the work not to be included inthe project plan. The scope statement will
be used to guide future projectrelated
decisions and to set stakeholder expectations.
DefinitionThe project's scope must be organized into smaller and moremanageable
packages of work. These work packages will require resourcesand time to complete.

Mission MCA

54

Mission MCA

VerificationOnce the project's scope has been defined, the project teamand stakeholders
must verify it to ensure that the work completed will infact support the project in achieving
its MOV.
Change ControlControls must be in place to manage proposed changes tothe project's
scope. Scope changes can either move the project closer to itsMOV or result in increased
work that drains the project's budget and causesthe project to exceed it scheduled deadline.
Proper scope control procedurescan ensure that the project stays on track.
Subdivide the Project into Phases
Once the project's scope has been defined and verified, the work of the project canbe
organized into phases in order to deliver the project's product. Phases are logicalstages.
Although the IT project methodology defines five high-level phases, IT projectsshould be
further divided into subphases that follow the phases of the systemsdevelopment life cycle
(SDLC).Breaking a project down into phases and subphases reduces complexity and risk.In
many cases it is easier to focus on the pieces instead of the whole; however, it isimportant
to never lose sight of the big picture. More specifically, each phase shouldfocus on providing
at least one specific deliverablethat is, a tangible and verifiablepiece of work. In addition,
a milestone is a significant event or achievement that providesevidence that that deliverable
has been completed and that the phase orsub-phase is complete.
TasksSequence, Resources, and Time Estimates
Once the project is divided into phases, tasks are then identified. A task may bethought of
as a specific activity or unit of work to be completed. Examples of sometasks in an IT project
may be to interview a particular user, write a program, or testlinks in a Web page. When
considering tasks, it is important to consider sequences,resources, and time.

Mission MCA

55

Mission MCA

Sequence Some tasks may be lineari.e., have to be completed in a particularsequence

while others can be completed in paralleli.e., at the same time.Performing parallel tasks
often provides an opportunity to shorten the overall lengthof the project. For example,
assume that a project has two tasksA and B. Task Awill require only one day to complete;
task B requires two days. If these tasks arecompleted one after the other, the project will
finish in three days. On the otherhand, if these tasks are performed in parallel, the length of
the project will be twodays. In this case, the length of the project is determined by the time
it takes to completethe longest task (i.e., task B). This simple example illustrates two
importantpoints:
(1) A project is constrained by the longest tasks, and
(2) any opportunity toperform tasks in parallel can shorten the project schedule.Resources
Resources on an IT project may include such things as technology, facilities(e.g., meeting
rooms), and people. Tasks require resources, and there is a costassociated with using a
resource. The use of a resource may be accounted for by usinga per-use charge or on a
prorated basisthat is, a charge for the time you use thatresource. For example, a
developer earns $50,000 a year and is assigned to work on atask that takes one day to
complete. The cost of completing that particular taskwould be prorated as $ 191 (assuming
an eight-hour, five-day work week).
Time It will take a resource a specific amount of time to complete a task. Thelonger it takes
a resource to complete a specific task, however, the longer the projectwill take to finish and
the more it will cost. For example, if we plan on assigning ourdeveloper who earns $50,000
a year to a task that takes two days, then we would estimatethe cost of completing that task
to be approximately $400. If the developer completesthe task in one half the time, then the
cost of doing that task will be about $200.Moreover, if the developer were then free to start
the next task, our schedule wouldthen be ahead by one day. Unfortunately, the reverse is
true. If we thought the taskwould take two days to complete (at a cost of $400) and it took
the developer threedays to complete, the project would be one day behind schedule and
$200 overbudget.
However, if two tasks could be performed in parallel, with our developerworking on Task A
(one day) and another $50,000/year-developer working on Task B(two days), then even if
Task A takes two days, our project schedule would not beimpactedas long as the
developer working on Task B completes the task within theestimated two days. While this
parallel work may save our schedule, our budget willstill be $200 over budget because task
A took twice as long to complete Understanding this relationship among tasks, resources,
and time will be importantwhen developing the project plan and even more important later
if it is necessary toadjust the project plan in order to meet schedule or budget constraints.
Schedule and BudgetThe Baseline Plan
The detailed project plan is an output of the project planning framework. Once thetasks are
identified and their sequence, resources required, and time-to-complete estimated,it is a
relatively simple step to determine the project's schedule and budget. Allof this information
can be entered into a project management software package thatcan determine the start
and end dates for the project, as well as the final cost.Once the project plan is complete, it
Mission MCA

56

Mission MCA

should be reviewed by the project manager,the project sponsor, and the project team to
make sure it is complete, accurate,and, most importantly, able to achieve the project's
MOV. Generally, the projectplan will go through several iterations as new information
becomes known or ifthere are compromises with respect to scope, schedule, and budget. In
addition,many of the details of the project plan are summarized in the project charter
inorder to provide a clearer picture as to how the plan will be carried out. Once theproject
plan is approved, it becomes the baseline plan that will serve as abenchmark to measure
and gauge the project's progress. The project manager willuse this baseline plan to compare
the actual schedule to the estimated schedule anthe actual costs to budgeted costs.

Mission MCA

57

Mission MCA

Unit 3: Project Scope management

3. 1 Scope definition and Project Scope management

Project Scope Management Processes
The Project Management Body of Knowledge (PMBOK) defines five processes to supportthe
knowledge area of project scope management, as shown in Table 5.1. Thisprocess group
begins with a scope initiation process whereby the project sponsor gives

the project manager the authority and resources to define the scope of the project. In
thecontext of the IT project methodology, the authority to commit time and resources
todefine the project's scope is included in the second phase when the project charter
andproject plan are developed.Once the commitment and resources to develop the project
charter and plan are inplace, the next process focuses on scope planning. This planning
process entailssetting the boundary of the project in order to determine what is and what is
not to beincluded in the project work.The third process centers on scope definition. While
scope planning defines theproject boundary, scope definition identifies the project
deliverables (as identified inthe IT project methodology) and the product deliverables (the
high-level functionalityor features of the IT product to be delivered by the project team). As
a result, theboundary and deliverables defined by the scope planning and definition
processesprovide a key component for developing the project charter and plan. Moreover,
theboundary and deliverables become critical inputs for estimating the project's
scheduleand budget.
Once the scope is defined, the process of scope verification confirms that thescope is
complete and accurate. The project team and sponsor must agree to all of theproject
deliverables. This not only sets expectations, but also focuses the project teamon what
needs to get done and what is outside the scope of the project.Time and resources will be
Mission MCA

58

Mission MCA

wasted needlessly if the scope of the project isnever defined accurately or agreed upon.
However, changes to the scope may beinevitable as new information becomes available or
if the needs of the organizationchange. Therefore, a process called scope change control is
needed to handle thesechanges so that if a scope change is appropriate, the change can be
approved in orderto amend the project's schedule and budget accordingly.
In addition, scope changecontrol procedures also protect the scope boundary from
expanding as a result ofincreasing featurism, requests by project stakeholders to keep
adding additionalfeatures and functions (i.e., bells and whistles) to the project once the
scope hasbeen set. Remember that the scope, schedule, and budget relationships suggest
thatincreasing the project's scope (i.e., expanding the scope boundary) will generallyrequire
an increase in schedule and budget. Therefore, adding additional work to theproject's scope
will ultimately lead to a project that misses its deadline and costsmore than originally
estimated. Subsequently, once the project' scope has been set, approved changes to the
project's scope must be reflected inthe project's baseline plan.Together, the processes and
techniques for defining and managing scope make upthe scope management plan.
Depending on the size and nature of the project, thisplan can be separate and/or
summarized in the project charter. Regardless, the proceduresfor defining and managing
the scope of a project must be communicated andunderstood by all of the project's
stakeholders to minimize the likelihood of misunderstandings.Moreover, the project's scope
must align and support the project'sMOV. Why spend time and resources to perform work
that will not add any value tothe organization or help the project achieve its MOV? Again,
work that does not addvalue consumes valuable time and resources needlessly. Figure 5.1
summarizes thecomponents and processes of a scope management plan.
PROJECT SCOPE INITIATION
Scope initiation provides a beginning process that formally authorizes the projectmanager
and team to develop the scope management plan. In terms of the IT projectmethodology,
this authorization is given after the project is formally accepted andfunds are committed to
developing the project charter and plan by the project sponsoror client. The business case
provides important information about the project'sdescription, MOV, risks, assumptions,
and feasibility. In addition, the business caseprovides information about the background of
the project in terms of why it was proposedand how it aligns with the organization's overall
strategic plan.

Mission MCA

59

Mission MCA

Project Scope Planning

Failure to define what is part of the project, as well as what is not, mayresult in work being
performed that was unnecessary to create the productof the project and thus lead to both
schedule and budget overruns.Olde Curmudgeon, PM Network Magazine, 1994.Scope
planning is a process for defining and documenting the project work. Morespecifically, a
project's scope defines all the work, activities, and deliverables that theproject team must
provide in order for the project to achieve its MOV. It is an importantstep in developing the
project plan since one must know what work must be done beforean estimate can be made
on how long it will take and how much it will cost.
Scope Boundary
Defining the scope boundary is the first step to establishing what is, and what is not, partof
the project work to be completed by the project team. Think of the scope boundaryas a
fence designed to keep certain things in and other things out. As Figure 5.2illustrates, any
work within the scope boundary should include only the work oractivities that support the
project's MOV. This work is what we want to capture andkeep within our fence. On the
other hand, a project team can spend a great deal of timedoing work and activities that will
not help the project achieve its MOV. As a result, theproject will consume time and
resources with very little return. Therefore, the scopeboundary must protect the scope from
these activities once it is set and agreed upon bythe project stakeholders. Having a clear and

Mission MCA

60

Mission MCA

agreed upon definition of the project MOVis critical for defining and managing the scope
boundary.
The Scope Statement
One way to define the scope boundary is to create a scope statement that documents
theproject sponsor's needs and expectations. For example, let's say we are outside
consultantshired to develop an electronic commerce application
application for a bank. After
developing andpresenting a business case to our client, we have been given the authority to
develop theproject charter and plan. Although the business case provides a great deal of
relevantinformation, we will still set up several meetings
meetings and interviews with
keystakeholders in the bank. Based upon these meetings and interviews,we create a scope
statement.
Scope Statement
1. Develop a proactive electronic commercestrategy thatidentifies the processes, products,
andservices to bedelivered
d through the World Wide Web.
2. Develop an application system that supportsall of theprocesses, products, and services
identifiedin the electronic commerce strategy.
3. Integrate the application system with thebank's existingenterprise resource planning
system.
It is just as important to clarify what work is not to be included, that is, what work is
Figure 5.2 Scope Boundary outside the scope of the project. Often

the

scope of a project is defined through interviews, meetings, or brainstorming

sessions.Stakeholders
takeholders often suggest ideas that are interesting, but not feasible or
appropriatefor the current project.Let's say that in our example a certain bank vice
president pushed for a customerrelationship management (CRM) and a data mining
component to beincluded
luded in the application system. The bank's president, however, has
decided thatthe time and effort to add these components cannot be justified because
launchingthe Web site in eight months is vital to bank's competitive strategy. Let's
alsoassume that conducting
ducting technology and organizational assessments of our
client'scurrent environment is an important piece of our project methodology. But
becausethe bank would like to control some of the costs of this project, we agree that its
Mission MCA

61

Mission MCA

ITdepartment will conduct that study. The results of this study will then be documentedand
provided to us.In this case, it is critical that we define explicitly both what is and what is not
partof the project scope. Individuals from both organizations may believe that specific
project work (i.e., the assessment study), system features, or functionality (i.e., CRMand
data mining) will be part of this project. These beliefs may result in misunderstandingsthat
lead to false expectations or needless work. To manage these expectations,it is useful to list
explicitly what is not part of the project's scope.
Out of Scope for this Project
1. Technology and organizational assessment of the current environment
2. Customer resource management and data mining componentsSetting the scope
boundary for the project not only sets expectations, but also candefine the constraints of
the project and how the product of the organization fitswithin the organization, that is, the
system must integrate with the organization'sexisting systems.The scope statement
provides a very general and high-level view of the projectwork and provides only a starting
point for defining the scope of our project. At thebeginning of a project understanding of
the project's scope may be limited. However,as we work more closely with our client more
information is uncovered and ourunderstanding of the project increases. Subsequently, the
project scope will evolvefrom being very general and high level to more detailed and
defined.
PROJECT SCOPE DEFINITION
Developing a scope statement is a useful first step for defining the scope of the projectand
setting a boundary. A project's scope, however, should also be defined in termsof the
deliverables that the team must provide. These deliverables can be dividedinto projectoriented deliverables and product-oriented deliverables. This separationgives the team a
clearer definition of the work to be accomplished and improves thelikelihood of accurately
assigning resources and estimating the time and cost ofcompleting the work. Moreover, a
clear definition of the project's deliverables setsunambiguous expectations and agreement
among all of the project stakeholders.
Project-Oriented Scope
Project-oriented deliverables, or scope, support the project management and IT
development
processes that are defined in the information technology project methodology(ITPM).
Project scope includes such things as the business case, project charter, andproject plan and
defines the work products of the various ITPM phases. Project-orienteddeliverables also
include specific deliverables such as a current systems study,requirements definition, and
the documented design of the information system. Theseare deliverables supported by the
systems development life cycle (SDLC) componentof the overall ITPM.Project-oriented
deliverables require time and resources and, therefore, must bepart of the overall project
schedule and budget. Their role is to ensure that the projectprocesses are being competed
so that the project's product (i.e., the information system)achieves the project's MOV and
objectives. Project-oriented deliverables alsoprovide tangible evidence of the project's
Mission MCA

62

Mission MCA

progress (or lack of progress). Finally, theyallow the project manager to set a baseline for
performance and quality controlbecause they usually require some form of approval before
work on the next projectphase or deliverable begins.Project-Oriented Scope Definition Tools
All of the project deliverables must have a clear a d concise definition. One way to
communicate the project's deliverables is tocreate a deliverable definition table (DDT).
An example of a DDT for our bank'selectronic commerce system is illustrated in Table
5.2.The purpose of the DDT is to define all of the project-oriented deliverables to
beprovided by the project team. Each deliverable should have a clear purpose. In addition,it
is important to define the structure of the deliverable. For example, a deliverablecould be a
document (paper or electronic), prototype, presentation, or theapplication system itself.
This sets the expectation of what will be delivered by theproject team. Moreover, the
standards provide a means to verify whether the deliverablewas produced correctly. These
standards could be defined within the IT Projectmethodology, controlling agency (e.g.,
International Organization forStandardization), or through various quality standards
established by the organization.Each deliverable must be verified and approved generally by
the project sponsorand/or the project manager. It is important that the responsibility for
approving adeliverable be clearly defined as well. Once a deliverable is approved, the
projectteam is authorized to begin work on the next deliverable. This provides
authorizationcontrol as well as a basis for logically sequencing the work. Finally, it is
importantthat the resources required to complete the deliverable be defined. This will
providethe foundation for determining not only what resources will be needed for the
project,but also for estimating the time and cost in completing each deliverable.

Mission MCA

63

Mission MCA

Once the deliverables have been defined in the DDT, a deliverable structurechart (DSC) can
be developed as an interim step to define detailed work packagesthat will be used to
estimate the project schedule and budget. Later on, these workpackages will be used to
create a work breakdown structure (WBS)a tool usedto help create the project plan. For
example, Figure 5.3 provides an example of aDeliverable Structure Chart that maps the
project life cycle and systems development lifecycle phases to the deliverables defined in
the DDT.
Product-Oriented Scope
Although the electronic commerce application system is listed as a projectorienteddeliverable, we really do not have any idea what exactly will be delivered to
theclient. In general, the application system will be the largest project deliverable andwill,
Mission MCA

64

Mission MCA

therefore, require the most time and resources to complete. Identifying the featuresand
functionality of the application system (and their complexity) will be pivotalfor estimating
the time and cost of producing this deliverable.Product-Oriented Scope Definition Tools
Product scope therefore focuses onidentifying the features and functionality of the
information system to be implemented.

A useful tool for refining the scope boundary and defining what the system must do is a
modelling tool called a context level data flow diagram (DFD). A DFD is a processmodel that
has been available for quite some time and is often taught in systems analysisand design
courses. A context level DFD, however, presents a high-level representationof the system
that has one process (i.e., a circle or rounded rectangle that representsthe system as a
whole) and depicts all the inflows and outflows of data and informationbetween the system
and its external entities. The external entities are usually representedby a square and can be
people, departments, or other systems that provide or receiveflows of data. Arrows
represent the directional flow of data between external entitiesand the system. Each arrow
and entity should be labeled appropriately. Lower levelDFDs can be developed later to
model the processes and flows of data in greater detail.An example of a context level DFD
for our banking electronic commerce system isprovided in Figure 5.4. As you can see, the
high level features and functionality of thesystem focus on what the system must do.
Another useful tool for defining the product scope is the use case diagram,which has been
used in the object-oriented world as part of the Unified ModelingLanguage (UML). While
Jacobson (Jacobson, Cristerson et al. 1992) introduced theuse case as a tool for software
development, a use case diagram can provide a highlevel model for defining, verifying, and
reaching agreement upon the product scope.The use case diagram is a relatively simple
diagram in terms of symbols and syntax,but it is a powerful tool for identifying the main
functions or features of the system andthe different users or external systems that interact
with the system. At this early stageof the project, the use case can provide a high level
diagram that can be further refinedand detailed during requirements analysis later in the
project.Actors are people (i.e., users, customers, managers, etc.) or external systems
Mission MCA

65

Mission MCA

(i.e.,the bank's ERP system) that interact, or use, the system. Think of actors in terms ofroles
(e.g., customer) instead of as specific individuals (e.g., Tom Smith). A use case,

actors. When developing a use case diagram, actors are identified using stick figures,while
use cases are defined and represented using ovals. Figure 5.5 provides anexample of a use
case diagram for the bank example.As you can see in Figure 5.5, the use case diagram
provides a simple yet effectiveoverview of the functions and interactions between the use
cases and the actors. Thebox separating the use cases from the actors also provides a
system boundary thatdefines the scope boundary. Use cases inside the boundary are
considered within thescope of the project, while anything outside of the boundary is
considered outside thescope of the project. Listing the actors provides an opportunity to
identify variousstakeholders and can be useful for understanding the needs of the
organization as awhole. It can be useful not only for addressing competing needs among
various stakeholders,but also for identifying security issues as well (Fowler and Scott 1997).
Thedevelopment of a use case diagram is an iterative process that can be developed during
ajoint application development (JAD) session. JAD is a group-based method wherethe users
and systems analysts jointly define the system requirements or design thesystem (Turban,
Rainer and Potter 2001).The use case diagram used to define the product scope can be used
to refine thelevel of detail and functionality later on in our project. Following our example,
theuse case diagram in Figure 5.5 identifies the customer actor as using the system
totransfer payments. However, a scenario or set of scenarios could be developed duringthe
Mission MCA

66

Mission MCA

analysis and design phases of our project to determine how a customer wouldtransfer funds
successfully, while another scenario might focus on what happenswhen a customer has
insufficient funds in their account. This level of detail is moresuited to the requirements
definition rather than the scope definition. At this point, it ismore important to identify that
the system must allow a customer to transfer funds thanto identify how the funds may be
transferred. Later on, the product scope can becompared or measured against the detailed
requirements. These detailed requirementswill be defined during the SDLC component of
the ITPM.But what is the appropriate level of detail for defining the product scope?Knowing
the right level of detail is more an art than a science. The right level allowsthe project
manager to estimate the time it will take to produce the application systemaccurately.
As the next chapter shows, estimating the time and effort to produce theapplication system
deliverable depends on the size of the application, the number offeatures incorporated, and
their level of complexity. Therefore, the quality of theestimates will be greatly influenced by
our understanding of the information system tobe delivered.The time and resources
committed to developing the project charter and plan maylimit the amount of time and
energy we can devote to defining the details of the informationsystem. Thus, the objective
during this planning stage of the project should be tosecure enough detail about the
information system to allow us to estimate the time andeffort needed to produce this
deliverable. During the analysis and design phases, wecan commit more time and resources
to increasing our understanding and to documentingthe level of detail needed to built and
deliver the system.

3.2 Creating the Work Breakdown Structures

the scope definition process, several tools and techniques were introduced. Forexample, the
deliverable definition table (DDT) and deliverable structure chart (DSC)identify the
deliverables that must be provided by the project team.Once the project's scope is defined,
the next step is to define the activities or tasksthe project team must do to fulfil the scope
deliverable requirements. The work breakdownstructure (WBS) is a useful tool for
developing the project plan and links the project'sscope to the schedule and budget.
According to Gregory T. Haugan (2002),The WBS represents a logical decomposition of the
work to be performedand focuses on how the product, service, or result is
naturallysubdivided.
It is an outline of what work is to be performed. (17)The WBS provides a framework for
developing a tactical plan to structure theproject work. PMBOK originally defined the WBS
as a "deliverable-oriented hierarchy,"but much debate and confusion has existed as to what
a WBS should look likeand how one should be built. Recently, the Project Management
Institute formed acommittee to recommend standards for the WBS. That committee
recommends thatno arbitrary limits should be imposed because the WBS should be
flexible.Subsequently, the WBS can be used in different ways depending on the needs of
theproject manager and team.

Mission MCA

67

Mission MCA

Work Packages
The WBS decomposes, or subdivides, the project into smaller components and
moremanageable units of work called work packages. Work packages provide a logical
basisfor defining the project activities and assigning resources to those activities so that all
theproject work is identified (Haugan 2002). A work package makes it possible to develop
aproject plan, schedule, and budget and then later monitor the project's progress.

As illustrated in Figure 6.1, a work packagemay be viewed as a hierarchy that starts with
theproject itself. The project is then decomposed intophases, with each phase having one or
more deliverables as defined in the deliverable definitiontable and deliverable structure
chart. Morespecifically, each phase should provide at least onespecific deliverablethat is,
a tangible andverifiable piece of work. Subsequently, activities ortasks are identified in order
to produce the project'sdeliverables.
Deliverables and Milestones
One departure from most traditional views of a WBS is the inclusion of milestones.
Amilestone is a significant event or achievement that provides evidence that thatdeliverable
has been completed or that a phase is formally over.Deliverables and milestones are closely
related, but they are not the same thing.Deliverables can include such things as
presentations or reports, plans, prototypes,and the final application system. A milestone, on
the other hand, must focus on anachievement. For example, a deliverable may be a
prototype of the user interface, butthe milestone would be a stakeholder's formal
acceptance of the user interface. Onlythe formal acceptance or approval of the user
interface by the project sponsor wouldallow the project team to move on to the next phase
of the project.In theory, if a project team succeeds in meeting all of its scheduled
milestones,then the project should finish as planned. Milestones also provide several
otheradvantages. First, milestones can keep the project team focused.
It is much easier toconcentrate your attention and efforts on a series of smaller, short-term
deliverablesthan on a single, much larger deliverable scheduled for completion well into
Mission MCA

68

Mission MCA

thefuture. On the other hand, if milestones are realistic, they can motivate a project team
iftheir attainment is viewed as a success. If meeting a milestone signifies an importantevent,
then the team should take pleasure in these successes before gearing up for thenext
milestone.Milestones also reduce the risk of a project. The passing of a milestone,
especiallya phase milestone, should provide an opportunity to review the progress of
theproject. Additional resources should be committed at the successful completion ofeach
milestone, while appropriate plans and steps should be taken if the project cannotmeet its
milestones.Milestones can also be used to reduce risk by acting as cruxes or proof of
concepts.Many times a significant risk associated with IT projects is the dependency onnew
technology or unique applications of the technology.
A crux can be the testing ofan idea, concept, or technology that is critical to the project's
success. For example,suppose that an organization is building a data warehouse using a
particular vendor'srelational database product for the first time. A crux for this project may
be the collectionof data from several different legacy systems, cleansing this data, and
thenmaking it available in the relational database management system. The team
mayensure that this can be accomplished using only a small amount of test data. Once
theproject team solves this problem on a smaller scale, they have proof that the concept
ortechnique for importing the data from several legacy systems into the data warehousecan
be done successfully. This breakthrough can allow them to incorporate what theyhave
learned on a much larger scale. Subsequently, solving this crux is amilestone that would
encourage the organization to invest more time and resources tocomplete the project.
Milestones can also provide a mechanism for quality control. Continuing withour example,
just providing the users with an interface does not guarantee that it willbe acceptable to
them. Therefore, the completion of user interface deliverable shouldend only with their
acceptance; otherwise, the team will be forced to make revisions.In short, the deliverable
must not only be done, but must be done right.
Developing the WBS
Developing the WBS may require several versions until everyone is comfortable
andconfident that all of the work activities have been included. It is also a good idea
toinvolve those who will be doing the workafter all, they probably know what has tobe
done better than anyone else.The WBS can be quite involved, depending upon the nature
and size of the project.To illustrate the steps involved, let's continue with our electronic
commerce projectexample from the last chapter. As you may recall, we created a DDT and
DSC to definethe scope of the project. To make things easier to follow, let's focus on only
oneportion of the projectcreating a document called the test results report. Figure 6.2
provides the DSC that we developed in Chapter 5. As you can see, two deliverablesthe
test plan and test results reportare to be completed and deliveredduring the testing
phase of the project.The DSC defines the phases and deliverables for our project. The next
step is todevelop sets of work packages for each of the phases and deliverables. After a
teammeeting, let's say that we have identified and discussed several activities that we need
todo in order to produce the test results document:

Mission MCA

69

Mission MCA

Review the test plan with the client so that key stakeholders are clear as to whatwe will be
testing, how we will conduct the tests, and when the tests

Figure 6.2 Deliverable Structure Chart (DSC) for EC Example

will be carried out. This review may be done as a courtesy or because weneed specific
support from the client's organization and, therefore, mustinform them when that support
will be required.
After we have informed the client that we will test the system, we basicallycarry out the
tests outlined in the test plan.
Once we have collected the test results, we need to analyze them.
After we analyze the results, we will need to summarize them in the formof a report and
presentation to the client.
If all goes well, then the client will approve or signoff on the test results.Then, we can
move on to the implementation phase of our project. If alldoes not go well, we need to
address and fix any problems. Keep in mind,that the test phase is not complete just because
we have developed a testplan and created a test report. The client will sign off on the test
resultsonly if the system meets certain predetermined quality standards.Figure 6.3 provides
an example of a WBS with the details shown for only the testingphase of the project. As you
can see, the WBS implements the concept of a workpackage for the project, phase,
deliverable, task/activity, and milestone componentsthat were illustrated in Figure 6.1.
This particular WBS follows an outline format with acommonly used decimal numbering
system that allows for continuing levels ofdetail.1 If a software package is used to create the
WBS, signs in front of each itemcan either hide or show the details. For example, clicking on
"-6.2 Test ResultsReport" would roll up the details of this work package into "+6.2 Test
ResultsReport". Similarly, clicking on any item with a "+" in front of it would expand
thatitem to show the details associated with it.The skills to develop a useful WBS generally
evolve over time with practice andexperience. Everyone, experienced or not, should keep in
mind the following pointswhen developing a WBS.The WBS Should Be Deliverable-Oriented

Mission MCA

70

Mission MCA

Remember, the focus of a project shouldbe to produce something, not merely on

completing a specified number of activities.
Although the WBS does not provide for any explicit looping, some activities may haveto be
repeated until the milestone is achieved. For example, software testing mayuncover a
number of problems or bugs that make the software system unacceptable tothe client. As a
result, these problems will have to be addressed and fixed and the sametests may have to
be conducted again. This process may be repeated a number oftimes (while consuming the
project schedule and budget) until the quality standardsare met.
The WBS Should Support the Project's MOV The WBS should include only tasks oractivities
that allow for the delivery of the project's deliverables. Before continuingwith the
development of the project plan, the project team should ensure that the WBSallows for the
delivery of all the project's deliverables as defined in the project's scope.In turn, this will
ensure that the project is more likely to achieve its MOV.

Mission MCA

71

Mission MCA

Haugen (2002) also suggests that the 100 percent rule is the most important criterion inthe
developing and evaluating the WBS. The rule states: "The next level decompositionof a WBS
element (child level) must represent 100 percent of the work applicable tothe next higher
(parent) element." (17) In other words, if each level of the WBSfollows the 100 percent rule
down to the activities, then we are confident that 100percent of the activities will have
been identified when we develop the projectschedule. Moreover, 100 percent of the costs
or resources required will be identifiedwhen we create the budget for our project.
The Level of Detail Should Support Planning and Control The WBS provides abridge between
the project's scope and project planthat is, the schedule andbudget. Therefore, the level
of detail should support not only the development of theproject plan but also allow the
project manager and project team to monitor and comparethe project's actual progress to
Mission MCA

72

Mission MCA

the original plan's schedule and budget. The two mostcommon errors when developing a
WBS are too little or too much detail. Too littledetail may result in a project plan that
overlooks and omits important activities andtasks. This will lead to an overly optimistic
schedule and budget. On the other hand,the WBS should not be a to-do list of one-hour
tasks. This excessive detail results inmicromanagement that can have several adverse
effects on the project. First, this mayimpact the project team's morale because most people
on projects are professionalswho do not want someone constantly looking over their
shoulders. Second, the progressof each and every task must be tracked. As a result, the
project plan will either not beupdated frequently or clerical staff will have to be hired (at a
cost to the project) just tokeep everything current.
Developing the WES Should Involve the People Who Will Be Doing the Work Oneway to
ensure that the WBS has the appropriate level of detail is to ensure that thepeople who do
the work are involved in its development. A person who has experienceand expertise in a
particular area probably has a better feel for what activities need tobe performed in order
to produce a particular project deliverable. Although the projectmanager is responsible for
ensuring that a realistic WBS is developed, the people whomust carry out the activities and
tasks may be more committed to the plan if they areinvolved in its development.Learning
Cycles and Lessons Learned Can Support the Development of a WBSBy using the concept of
learning cycles, the project team can focus on what they know(the facts), what they think
they know (assumptions), and what they need to find out(research) in order to develop a
more useful WBS. Lessons learned from previousprojects can be helpful in ensuring that the
WBS and subsequent project plan are realisticand complete.

3.3 Scope Verification

Once the project's scope has been defined, it must be verified. Project scope verificationis
the scope management process that provides a mechanism for ensuring thatthe project
deliverables are completed according to the standards described in the

Mission MCA

73

Mission MCA

Mission MCA

74

Mission MCA

deliverables are completedand completed correctly. This checklist has beenadapted to

include the MOV concept.
MOVAre the project's MOV clearly defined and agreed upon? Failure todefine and agree
upon the MOV could result in scope changes later in the project, which can lead to added
work impacting the project's schedule and budget.
DeliverablesAre the deliverables tangible and verifiable? Do they supportthe project's
MOV?
Quality standardsAre controls in place to ensure that the work was notonly completed,
but also completed to meet specific standards?
MilestonesAre milestones defined for each deliverable? Milestones aresignificant events
that mark the acceptance of a deliverable and give theproject manager and team the
approval to begin working on the next deliverable. In short, milestones tell us that a
deliverable was not only completed, but also reviewed and accepted.
Review and acceptanceAre both sides clear in their expectations? Theproject's scope
must be reviewed and accepted by the project stakeholders.The project sponsor must
formally accept the boundary, product to be produced, and the project-related deliverables.
The project team must be clearon what it must deliver. In both cases, expectations must be
realistic andagreed upon.

3.4 Scope Control

According to the PMBOK, scope change control is concerned with ensuring that anychanges
to the project scope will be beneficial, with determining that an actual scopechange has
occurred, and with managing the actual changes when and as they occur.Scope control is
also concerned with:
Scope gropeScope grope is a metaphor that describes a project team'sinability to define
the project's scope. This situation is common early in aproject when the project team and
sponsor have trouble understanding whatthe project is supposed to accomplish. Scope
grope can be minimized byhaving a clearly defined MOV and by following or applying the
processes,concepts, and tools described in this chapter.
Scope creepScope creep refers to increasing featurism, adding small yettime- and
resource-consuming features to the system once the scope of theproject has been
approved. For example, a project sponsor may try to addvarious bells and whistles to the
project scope. Yet, scope creep does notalways come from the project sponsor side. The
project team itself may comeacross interesting or novel ideas as the project work
progresses. Its enthusiasm for adding these ideas can divert its attention or add features
and functions to the system that the project sponsor did not ask for and does not
need.Scope creep must be identified and controlled throughout the project becauseit will
lengthen the project schedule and, in turn, lead to cost overruns.

Mission MCA

75

Mission MCA

Scope leapIf scope creep is caused by increasing featurism, scope leapsuggests a

fundamental and significant change in the project scope. Forexample, the original scope for
the bank's electronic commerce project wasto provide new products and services to its
customers. Scope creep may beadding a new feature, such as a new product or service, not
originally definedin the project's scope. Scope leap, on the other hand, is an impetus to
changethe project so that the electronic commerce system would allow the bank toobtain
additional funding in the open market. Adding this activity woulddramatically change the
entire scope and focus of the project. Scope leap canoccur as a result of changes in the
environment, the business, and thecompetitive makeup of the industry. Scope leap entails
changing the MOVand, therefore, requires that the organization rethink the value of the
currentproject. If this change is critical, the organization may be better off pulling theplug on
the current project and starting over by conceptualizing and initiatinga new project.
Scope Change Control Procedures
A scope change procedure should be in place before the actual work on the
projectcommences. It can be part of, or at least referenced in, the project charter so that it
iscommunicated to all project stakeholders. This procedure should allow for the
identificationand handling of all requested changes to the project's scope. Scope
changerequests can be made, and each request's impact on the project can be assessed.
Then, adecision whether to accept or reject the scope change can be made.
A scope change procedure may include a scope change request form. An exampleof a scope
change request form is illustrated in Figure 5.6. The individual or groupmaking the scope
change request should complete the form.Regardless of the format for a scope change
request form, it should containsome basic information. First, the description of the change
request should beclearly defined so that the project manager and project team understand
fully thenature and reason for the scope change. Second, the scope change should be
justified,which separates the would likesfrom the must haves. In addition,
severalalternatives may be listed in order to assess the impact on scope,
schedule,resources, and cost. Often a trade-off or compromise will be suitable if the
impactof the scope change is too great. The project sponsor must understand and
approvethese impacts because the baseline project plan will have to be adjusted
accordingly.Alternatives may include reducing functionality in other areas of the
project,extending the project deadline, or adding more resources in terms of staff,
overtime,or technology.
Finally, all scope changes must be approved so that additionalresources can be committed
to the project.However, nothing can be more frustrating than making a request and then
not hearing anything. Too often requests fall through the cracks, leading to credibility
concernsand accusations that the project manager or project team is not being responsiveto
the client's needs. Therefore, a scope change control procedure should be loggedwith the
intention that each request will be reviewed and acted upon. As seen in Figure5.7, an
example of a Change Request Log includes information as to who has theauthority to make
the scope change decision and when a response can be expected.Although this may seem
like the beginning of a bureaucracy, it is really designedto protect all project stakeholders.
Too often the project manager and project team feelthe pressure to say yes to each and
Mission MCA

76

Mission MCA

every scope change request because their refusalmay be interpreted as being

uncooperative. Unfortunately, introducing scope creepwill impact the schedule and budget.
As the deadline passes or as costs begin to overrunthe budget, the project manager and
team then may come under fire for not controllingthe project objectives.

Figure 5.6 Scope Change Request Form

Mission MCA

77

Mission MCA

Figure 5.7 Scope Change Request Log

Still, a project manager and team should not say no to every scope change request.Some
changes will be beneficial and warranted as the project proceeds. The questionthen
becomes, What should be the basis for making a scope change decision?As you have seen,
the project's MOV guides the project planning process.Similarly, the project's MOV can also
guide scope change decisions. A scope changerequest should be approved ifand only if
the scope change can bring the projectcloser to achieving its MOV; otherwise, why bother
adding additional work, resources,time, and money to activities that will not bring any value
to the organization?
Benefits of Scope Control
The most important benefit of scope change control procedures is that they keep theproject
manager in control of the project. More specifically, they allow the projectmanager to
manage and control the project's schedule and budget. Scope control proceduresalso allow
the project team to stay focused and on track in terms of meetingits milestones because it
does not have to perform unnecessary work.

Mission MCA

78

Mission MCA

Unit IV:Scheduling and Budgeting

4.1 Developing the Project Schedule
Overeager new manager promises his boss a thirty-day schedule for aproject to automate
passwords on company's mainframe,midrange, and desktop systems. "We can't do that,"
desktop supportpilot fish tells manager when he sees the project plan. "Have youconfirmed
that the mainframe and midrange support groups can dothe product evaluation in the three
days you've allotted?" fish asks."No," says manager, "but if they don't meet the plan, then
it'll betheir fault it fails, not mine."The WBS identifies the activities and tasks that must be
completed in order to providethe project scope deliverables. Estimates provide a forecasted
duration for each of theseactivities and are based upon the characteristics of the activity,
the resources assigned,and the support provided to carry out the activity. Project networks,
on the other hand,support the development of the project schedule by identifying
dependencies and thesequencing of the activities defined in the WBS.
The project network also serves as a keytool for monitoring and controlling the project
activities once the project work begins.In this section, several project management tools
and techniques will be introduced to createa project network plan that defines the
sequence of activities throughout theproject and their dependencies. These tools include
Gantt charts, activity on the node(AON), critical path analysis, PERT, and the precedence
diagramming method (PDM).Many of these tools are integrated into most project
management software packages;however, it is important to have a fundamental
understanding of how these various projectmanagement tools work in order to make the
most of an automated tool.
Gantt Charts
Working with the U.S. Army during World War I, Henry L. Gantt developed a
visualrepresentation that compares a project's planned activities with actual progress
overtime. Although Gantt charts have been around for a long time, they are still one ofthe
most useful and widely used project management tools.Figure 7.2 shows how a basic Gantt
chart can be used for planning. Estimates forthe tasks or activities defined in the WBS are
represented using a bar across a horizontaltime axis. Other symbols, for example, diamonds,
can represent milestones tomake the Gantt chart more useful.The Gantt Chart in Figure 7.2
shows the general sequence of activities or worktasks. In this project example, there are five
tasks of varying durations and the projectshould be completed in fifteen time periods (e.g.,
days). In addition, the two shadeddiamonds following tasks C and E indicate milestone
events.Gantt charts can also be useful for tracking and monitoring the progress of a project.
As shown in Figure 7.3, completed tasks can be shaded or filled in, and one canget an
accurate picture of where the project stands for a given status or reporting date.In Figure
7.3, tasks A and B have been completed, but it looks like Task C is somewhatbehind
schedule.Although Gantt charts are simple, straightforward, and useful for
communicatingthe project's status, they do not show the explicit relationships among tasks
or activities.For example, we can see from Figure 7.3 that task C is somewhat behind
Mission MCA

79

Mission MCA

schedule;however, the Gantt chart does not tell us whether there will be an impact on tasks
Dor E and whether this impact will push back the project's original deadline. The Ganttchart
introduced in this section follows a more traditional form. As you will see, theGantt chart
used in most project management software packages today has beenmodified to overcome
these limitations.
Project Network Diagrams
Project network diagrams include several useful tools for planning, scheduling,
andmonitoring the project's progress. Similar to Gantt charts, project network diagrams

use the WBS as a basis to provide a visual representation of the workflow of activitiesand
tasks. However, project network diagrams also provide valuable information aboutthe
logical sequence and dependencies among the various activities or tasks.Subsequently, a
Mission MCA

80

Mission MCA

completion date or project deadline should be developed based on asound estimating

process rather than guesstimating a target date or a date set arbitrarilyby upper
management or the client.In addition, project network diagrams provide information
concerning when specifictasks must start and finish, and what activities may be delayed
without affectingthe deadline target date. In addition, the project manager can make
decisions regardingscheduling and resource assignments to shorten the time required for
those criticalactivities that will impact the project deadline.
Activity on the Node (AON)1
An activity or task focuses on producing a specificproject deliverable, generally takes a
specific amount of time to complete, andrequires resources. Activity on the Node (AON) is
a project network diagrammingtool that graphically represents all of the project activities
and tasks, as well as theirlogical sequence and dependencies. Using AON, activities are
represented as boxes(i.e. nodes) and arrows indicate precedence and flow.To construct an
AON network diagram, one begins with the activities and tasksthat were defined in the
WBS. Estimates for each activity or task defined in the WBSshould have an associated time
estimate. The next step is to determine which activitiesare predecessors, successors, or
parallel.
Predecessor activities are those activitiesthat must be completed before another activity can
be startede.g., a computer'soperating system must be installed before loading an
application package. On theother hand, successor activities are activities that must follow a
particular activity insome type of sequence. For example, a program must be tested and
then documentedafter it is compiled. A parallel activity is an activity or task that can be
worked on atthe same time as another activity. Parallel activities may be thought of as an
opportunityto shorten the project schedule; however, they also can be a trade-off since
doing morethan one thing at the same time can have a critical impact on project resources.
The activities, time estimates, and relationships for developing a simple corporateintranet
can be summarized in a table similar to Table 7.1.Once the relationships and time estimates
for each activity or task in the WBS havebeen developed, an AON project network diagram
can be created, as in Figure 7.4.The work in an AON flows from left to right. An activity
cannot begin until all ofits predecessor activities have been completed. For example, activity
F cannot beginuntil activities C and D are done.Critical Path Analysis At this point we have a
visual road map of our project.Moreover, the time estimates for each of the activities
determines the project scheduleand tells us how long our project will take to complete. This
is determined by lookingat each of the possible paths and computing the total duration for
each path, as shownin Table 7.2.As can be seen in Table 7.2, the longest path in the AON
network diagram is nineteendays. This number is significant for two reasons. First, this tells
us that our project isestimated to take nineteen days (i.e., the project deadline will be
nineteen days after theproject starts). Second, and perhaps more importantly, Path 4 is also
our critical path.

Mission MCA

81

Mission MCA

Table 7.2 Possible Activity Paths The critical path is the longest path in the project network
and is also the shortesttime in which the project can be completed.Identifying the critical
path is a major concern to theproject manager because any change in the duration ofthe
activities or tasks on the critical path will affect theproject's schedule. In other words, the
critical path haszero slack (or float). Slack, which is sometimes calledfloat, is
i the amount of
time an activity can be delayed,that is, take longer than expected, before it delays
theproject. For example, Activity E is not on the criticalpath. In fact, the only path that
includes Activity E isPath 5. Subsequently, the start of Activity
Activity E could bedelayed for two
days or take up to three days to completebefore the project schedule is affected. On the
other hand,Activities A, B, D, G, I, and J have no float becausedelayingtheir start or taking
longer to complete that we estimated will increase
increase the total duration of the project by the
same amount.
As a result, knowing the critical path can influence a project manager's decisions.For
example, a project manager can expedite, or crash, the project byadding resources to an
activity on the critical
itical path to shorten its duration. The projectmanager may even be able to
divert resources from certain activities, for example,Activity E because this activity has some
slack or float. Diverting resources willreduce the overall project schedule, but keep
kee in mind
Mission MCA

82

Mission MCA

that there may be atrade-off

offshortening
shortening the schedule by adding more resources
res
may
inflate the project' budget.
Another way to shorten the project schedule is to look for parallel activity
opportunities.Doing two, or several, activities that were originally planned to be
completedin sequence at the same time can shorten the critical path. It is known as fast
trackingthe
the project.Can the critical path change? The answer is absolutely! As a result, it is
imperativethat the project manager not only identify
identify the critical path, but also monitor
andmanage it appropriately. In fact, it is very possible for a project to have more than one
critical path.

PERT Program Evaluation and Review Technique (PERT) was developed inthe late 1950s to
help manage thee Polaris submarine project. At about the same time, theCritical Path
Method (CPM) was developed. The two methods are often combined andcalled
PERT/CPM.PERT uses the project network diagramming technique to create a visual
representationof the scheduled activities
activities that expresses both their logical sequence
andinterrelationships. PERT also uses a statistical distribution that provides probabilityfor
estimating when the project and its associated activities will be completed. Thisprobabilistic
estimate is derived
ived by using three estimates for each activity: optimistic,most likely, and
pessimistic.
An optimistic estimate is the minimum time in which an activity or task can becompleted.
This is a best-case
case scenario where everything goes well and there is little orno chance of
finishing earlier.A most likely estimate, as the name implies, is the normallyexpected time
required to complete the task or activity. A pessimistic estimate is tested after it is written.
Or, in other words, the code is written and then tested.
tested. This relationship is similar to the
successor and predecessor relationships used in the AON method.

Mission MCA

83

Mission MCA

Mission MCA

84

Mission MCA

Start-To-Start (SS)A start-to

to-start
start relationship between tasks or activitiesoccurs when two
tasks can or must start at the same time. Although the
the tasksstart at the same time, they do
not have to finish together
i.e.,
i.e., the tasks canhave different durations. A start-to-start
start
relationship would be one type ofparallel activity that can shorten a project schedule.
Finish-To-Finish (FF)Another
Another type of parallel activity is the finish-to
to-finishrelationship.
Here, two activities can start at different times, have differentdurations, but are planned to
be competed at the same time. Once bothof the FF activities are completed, the next
activity or set of activities
tivities can bestarted, or if no more activities follow, the project is
complete.
Start-To-Finish (SF)The
The start-to-finish
start finish relationship is probably the leastcommon and can
be easily confused with the finish-to-start
finish start relationship. ASF relationship, as illustrated
il
in
Figure 7.5, is exactly the opposite of a FSrelationship. In addition, a SF relationship means
Mission MCA

85

Mission MCA

that task A cannot end untiltask B starts. An example of a SF relationship in real life might be
a nurseworking at a hospital. This person may have to work until they are relievedby
another nurse who arrives to start the next shift.An advantage of using PDM is that the
project manager can specify lead and lagtimes for various activities. More specifically, lead
time allows for the overlapping ofactivities. For example, a project plan may have two
activities or tasks that have beenidentified as a finish-to-start relationship. These two
activities may be the setup ofcomputers in a lab followed by the installation of an operating
system on those computers.If we had two people, one to set up the computers and one to
install the operatingsystems on each computer, the project plan might specify a finish-tostar relationship where the installation of the operating systems cannot begin until all ofthe
computers have been set up in the lab. Based upon this project plan, the personwho installs
the operating system must wait and watch while the other person works.
Let's assume, however, that it takes about half the time to install an operating systemas it
does to set up a computer. Furthermore, there is no reason why the software personcannot
begin installing the operating system when the hardware person has about half ofthe
computers set up. In this case, both tasks will finish about the same time, and we
havecreated an opportunity to shorten the project schedule. By scheduling the task
ofinstalling the operating systems when the task of setting up the computers is fifty
percentcomplete, we have used the concept of lead time to our advantage.On the other
hand, let's suppose further that before our hardware person startssetting up the computers
in the lab, we want the lab walls to be painted. This would beanother finish-to-start
relationship because we would like to schedule the painting ofthe lab before we start
installing the computers. Using lead time in this case, however,would not make sense
because we do not want the hardware person and painters gettingin each other's way. In
this case, we may even want to give the freshly painted walls achance to dry before we
allow any work to be done in the lab. Therefore, we wouldlike to schedule a lag of one day
before our hardware person starts setting up thecomputers. Another way of looking at this
is to say we are going to schedule anegative lead day in our project schedule.

Mission MCA

86

Mission MCA

4.2 Schedule Control

The final process in project time management is controlling the schedule. Like scope control,
schedule control is a portion of the integrated change control process under project in
management. The goal of schedule control is to know the status of the schedule, influence
the factors that cause schedule changes, determine that the schedule has changed, and
manage changes when they occur. The main inputs to schedule control are the project
management plan, project schedule, work performance data, and organizational process
assets. Some of tools and techniques include:
Progress reports
A schedule change control system, operated as part of the integrated change control system
A scheduling tool and/or project management software, such as Project 2007 or similar
software
Schedule comparison bar charts, such as the Tracking Gantt chart
Variance analysis, such as analyzing float or slack
What-if scenario analysis, which can be done manually or with the aid of software
Adjusting leads and lags
Schedule compression, such as crashing and fast-tracking described earlier in this chapter
Performance measurement, such as earned value, described in Chapter 7, Proj-ect Cost
Management
Resource leveling, is described later, Project [Inman Resource Management The main
outputs of schedule control include work performance measurements, organizational
process assets updates, such :is lessons-learned reports related to schedule control, change
requests, project management plan updates, and project document updates.
There are many issues involved in controlling changes to project schedules. It is important
first to ensure that the project schedule is realistic. Many projects, especially in information
technology, have very unrealistic schedule expectations. It is also important to use discipline
and leadership to emphasize the importance of following and meeting project schedules.
Although the various tools and techniques assist in developing and managing project
schedules, project managers must handle several people-related issues to keep projects on
track. "Most projects fail because of people issues, not from failure to draw a good 238 PERT
chart.' Project managers can perform a number of reality checks that will help them manage
changes to project schedules. Several soft skills can help project managers to control
schedule changes.

Mission MCA

87

Mission MCA

4.3 Basic Principles of Cost Management

many information technology projects are never initiated because information technology
professionals do not understand the importance of basic accounting and finance principles.

Life cycle costing allows you to see a big picture view of the cost of a project throughout its
life cycle. This helps you to develop an accurate projection of a projects financial costs and
benefits. Life cycle costing considers the total cost of ownership, or development plus
support costs, for a project. For example, a company might complete a project to develop
and implement a new customer service system in one or two years, but the new system
could be in place for ten years. Project managers, with assistance from financial experts in
their organizations, should create estimates of the costs and benefits of the project for its
entire life cycle, or ten years in the proceeding example. Recall that the present value
analysis for the project would include the entire ten-year period of costs and benefits. Top
management and project managers need to consider the life cycle costs of project when
they make financial decisions.
Organization have a history of not spending enough money in the early phases of
information technology projects which impacts total cost of ownership, For example, it is
much more cost-effective to spend money on defining user requirements and doing early
testing on information technology projects than to wait for problems to appear after
implementation.
Since organization depends on reliable information technology, there are also huge costs
associated with downtime. For example Table 7-1 summarizes the average cost of a minute
of downtime for different IT applications. Costs include the cost to bring the system back up,
staff cost to make up for the lost work in production during the system downtime, and
direct and indirect lost revenue.

Mission MCA

88

Mission MCA

Table 7-1 cost of downtime for IT applications

Cash flow analysis is a method for determining the estimated annual costs and benefits for
a project and the resulting annual cash flow. Project managers must conduct cash flow
analysis to determine net present value. Most consumers understand the basic concept of
cash flow. If they do not have enough money in their wallets or checking accounts, they
cannot purchase something. Top management must consider cash flow concerns when
selecting projects in which to invest. If top management selects too many projects that have
high cash flow needs in the same year, the company will not be able to support all of its
projects and maintain its profitability. It is also important to define clearly the year on which
the company bases the dollar amounts. For example, if a company bases all costs on 2008
estimates, it would need to account for inflation and other factors when projecting costs
and benefits in future-year dollars.
Tangible and intangible costs and benefits are categories for determining how definable the
estimated costs and benefits are for a project. Tangible costs or benefits are those costs or
benefits that an organization can easily measure in dollars. For example, suppose the
Surveyor Pro project described in the opening case included a preliminary feasibility study. If
a company completed this study for $100,000, the tangible cost of the study is $100,000. If
Juan's government estimated that it would have cost $150,000 to do the study itself, the
tangible benefits of the study would be $50,000 if it assigned the people who would have
done the study to other projects.
Conversely, intangible costs or benefits are costs or benefits that are difficult to measure in
monetary terms. Suppose Juan and a few other people, out of personal interest, spent some
time using government-owned computers, books, and other resources to research areas
related to the study. Although their hours and the government-owned materials were not
billed to the project, they could be considered intangible costs. Intangible benefits for
Mission MCA

89

Mission MCA

projects often include items like goodwill, prestige, and general statements of improved
productivity that an organization cannot easily translate into dollar amounts. Because
intangible costs and benefits are difficult to quantify, they are often harder to justify.
Direct costs are costs that can be directly related to producing the products and services of
the project. You can attribute direct costs directly to a certain project. For example, the
salaries of people working hill time on the project and the cost of hardware and software
purchased specifically for the project are direct costs. Project managers should focus on
direct costs, since they can control them.
Indirect costs are costs that are not directly related to the products or ser-vices of the
project, but are indirectly related to performing the project. For example, the cost of
electricity, paper towels, and so on in a large building housing a thousand employees who
work on many projects would be indirect costs. Indirect costs are allocated to projects, and
project managers have very little control over them.
Sunk cost is money that has been spent in the past. Consider it gone, like a sunken ship that
can never be returned. When deciding what projects to invest in or continue, you should
not include sunk costs. For example, in the opening case, suppose Juan's office had spent $1
million on a project over the past three years to create a geographic information system,
but they never produced any-thing valuable. If his government were evaluating what
projects to fund next year and someone suggested that they keep funding the geographic
information system project because they had already spent I million on it, he or she would
be incorrectly making sunk cost a key factor in the project selection decision. Many people
tall into the trap of considering how much money has been spent on a failing project and,
therefore, hate to stop spending money on it. This trap is similar to gamblers not wanting to
stop gambling because they have already lost money. Sunk costs should be forgotten.
Learning curve theory states that when many items are produced repetitively, the unit cost
of those items decreases in a regular pattern as more units are produced. For example,
suppose the Surveyor Pro project would potentially produce 1000 handheld devices that
could run the new software and access information via satellite. The cost of the first
handheld device or unit would be much higher than the cost of the 1000th unit. Learning
curve theory should help estimate costs on projects involving the production of large
quantities of items. Learning curve theory also applies to the amount of time it takes to
complete some tasks. For example, the first time a new employee performs a specific task, it
will probably take longer than the tenth time that employee performs a very similar task.
Reserves are dollars included in a cost estimate to mitigate cost risk by allowing for future
situations that are difficult to predict. Contingency reserves allow for future situations that
may be partially planned for (some-times called known unknowns) and are included in the
project cost baseline. For example, if an organization knows it has a 20 percent rate of
turnover for information technology personnel, it should include contingency reserves to
Mission MCA

90

Mission MCA

pay for recruiting and training costs for information technology personnel. Management
reserves allow for future situations that are unpredictable (sometimes called unknown
unknowns). For example, if a project manager gets sick for two weeks or an important
supplier goes out of business, management reserve could be set aside to cover the resulting
costs.

4.4 Cost Estimating

Project managers must take cost estimates seriously if they want to complete projects within budget constraints. After developing a good resource requirements list, project managers
and their project teams must develop several estimates of the costs for these resources.
Recall from Chapter 6 that an important process in project time management is estimating
activity resources, which provides a list of activity resource requirements. For example, if all
activity on a project is to perform a particular type of test, the list of activity resource
requirements would describe the skill level of the people needed to perform the test, the
number of people and hours suggested to perform the test, the need for special software or
equipment, and so on. All of this information is required to develop a cost estimate. This
section describes various types of cost estimates, tools and techniques for estimating costs,
typical problems associated with information technology cost estimates, and a detailed
example of a cost estimate for an information technology project.

4.4.1 Types of cost estimates

One of the main outputs of project cost management is a cost estimate. Project managers
normally prepare several types of cost estimates for most projects. Three basic types of
estimates include the following:
A rough order of magnitude (ROM) estimate provides an estimate of what a project will
cost. ROM estimates can also be referred to as a ballpark estimate, a guesstimate, a swag,
or a broad gauge. This type of estimate is done very early in a project or even before a
project is officially started. Project managers and top 111:111:t0111CIlt use this estimate to
help make project selection decisions. The timeframe for this type of estimate is often three
or more years prior to project completion. A ROM estimate's accuracy is typically -50
percent to +100 percent, meaning the project's actual costs could be 50 percent below the
ROM estimate or 100 percent above. For example, the actual cost for a project with a ROM
estimate of $100,000 could range between $50,000 to $200,000. For information
technology project estimates, this accuracy range is often much wider. Many information
technology professionals automatically double estimates for software development because
of the history of cost overruns on information technology projects.
A budgetary estimate is used to allocate money into an organization's budget. Many
organizations develop budgets at least two years into the future. Budgetary estimates are
made one to two years prior to project completion. The accuracy of budgetary estimates is
Mission MCA

91

Mission MCA

typically -10 percent to +25 percent. meaning the actual costs could be 10 percent less or 25
percent more than the budgetary estimate. For example, the actual cost for a project with a
budgetary estimate of 5100,000 could range between 890,000 to $125,000. A definitive
estimate provides an accurate estimate of project costs. Definitive estimates arc used for
making many purchasing decisions for which accurate estimates are required and for
estimating final project costs.14 'r example.
if a project involves purchasing 1,000 personal e imputers from an outside supplier in the
next three months, a definitive estimate would be required to aid in evaluating supplier
proposals and allocating the funds to pay the chosen supplier. Definitive estimates are made
one year or less prior to project completion.
A definitive estimate should be the most accurate of the three types of estimates. The
accuracy of this type of estimate is normally -5 percent to +10 percent. meaning the actual
costs could be 5 percent less or 10 percent more than the definitive estimate. For example,
the actual cost for a project with a definitive estimate of 5100,000 could range between
$95,000 to 8110,000. Table 7-2 summarizes the three basic types of cost estimates.

The number and type of cost estimates vary by application area. For example, the
Association for the Advancement of Cost Engineering (ACE) International identifies five
types of cost estimates for construction projects: order of magnitude, conceptual.
preliminary, definitive, and control. The main point is that estimates are usually done at
various stages of project and should become more accurate as time progresses.
In addition to creating cost estimates, it is also important to provide supporting details for
the estimates. The supporting details include the ground rules and assumptions used in
creating the estimate, a description of the project (scope statement, WM, and so on) used
as a basis for the estimate, and details on the cost estimation tools and techniques used to
create the estimate. These supporting details should make it easier to prepare an updated
estimate or similar estimate as needed.

Mission MCA

92

Mission MCA

A cost management plan is a document that describes how the organization will manage
cost variances on the project. For example, if a definitive cost estimate provides the basis
for evaluating supplier cost proposals for all or part of a project, the cost management plan
describes how to respond to proposals that are higher or lower than the estimates. Some
organizations assume that a cost proposal within 10 percent of the estimate is acceptable
and only negotiate items that are more than In percent higher or 20 percent lower than the
estimated costs. The cost management plan is part of the overall project management plan
described in Chapter -1. Project Integration Management.

4.4.2 Cost estimation Tools and Techniques

As you can imagine, developing a good cost estimate is difficult. Fortunately, there are
several tools and techniques available to assist in creating one. Commonly used tools and
techniques include analogous cost estimating, bottom-up estimating, parametric modelling,
the cost of quality, project management estimating software, vendor bid analysis, and
reserve analysis.
Analogous estimates, also called top-down estimates. use the actual cost of a previous,
similar project as the basis for estimating the cost of the current project. This technique
requires a good deal of expert judgment and is generally less costly than others are, but it is
also let*: accurate. Analogous estimates are most reliable when the previous projects are
similar in fact, not just in appearance. In addition, the groups preparing cost estimates must
have the needed expertise to determine whether certain parts of the project %yin be more
or less expensive than analogous projects. For example, estimators often try to find a similar
project and then customize/modify it for known differences. however, if the project to be
estimated involves a new programming language or working with a new type of hardware or
network, the analogous estimate technique could easily result in too low an
estimate.Intranet Site project. You can also view the ResNet cost estimate on the
companion Web site for this text. This section includes a step-by-step approach for
developing a cost estimate for the Surveyor Pro project described in the opening case. Of
course, it is much shorter and simpler than a real cost estimate would be, but it illustrates a
process to follow and uses several of the tools and techniques described earlier.
For more detailed information on creating a cost estimate, sec the NASA Cost Estimating
Handbook and other references provided in the Suggested Readings on the companion Web
site. 266 Before beginning any cost estimate, you must first gather as much information as
possible about the project and ask how the organization plans to use the cost estimate. If
the cost estimate will be the basis for contract awards and performance reporting, it should
be a definitive estimate and as accurate as possible, as described earlier. It is also important
to clarify the ground rules and assumptions for the estimate. For the Surveyor Pro project
cost estimate, these include the following:
This project was preceded by a detailed study and proof of concept to show that it was
possible to develop the hardware and software needed by surveyors and link the new
devices to existing information systems. The proof of concept project produced a prototype
handheld device and much of the software to provide basic functionality and link to the
Mission MCA

93

Mission MCA

Global Positioning Systems (GPS) and other government databases used by surveyors. There
is sonic data avail-able to help estimate future labour costs, especially for the software
development. There is also scuttle data to help estimate the cost of the handheld devices.
The main goal of tins project is to produce 100 handheld devices, continue developing the
software (especially the user interface), test the new system in the field, and train 100
surveyors in selected cities on how to use the new sys-tem. A follow-up contract is expected
for a much larger number of devices based on the success of this project.
There is a WBS for the project, as shown below:
1. Project management
2. Hardware
2.1 Handheld devices
2.2 Servers
3. Software
3.1 Licensed software
3.2 Software development
4. Testing
5. Training and support
6. Reserves
Costs must be estimated by WBS and by month. The project manager will report progress
on the project using earned value analysis. which requires this type of estimate.
Costs will he provided in U.S. dollars. Since the project length is one year. inflation will not
be included.
The project will be managed by the government's project office. There will be a part-time
project manager and four team menu hers assigned to the project. The team members will
help manage various pans of the project and provide their expertise in the areas of software
development, training, and support. Their total hours will be allocated as follows: 25
percent to project management, 25 percent to software development, 25 percent to
training and support. and 25 percent to non-project work.
The project involves purchasing the handheld devices from the same company that
developed the prototype device. Based on producing 100 devices, the cost rate is estimated
to be 8600 per unit. The project will require four additional servers to run the software
required for the devices and for managing the project.
The project requires purchased software licenses for accessing the GPS and three other
external systems. Software development includes developing a graphical User interface for
the devices, an online help system, and a new module for tracking surveyor performance
using the device. Testing costs should be low due to the success of the prototype project. Au
estimate based on 10 percent multiplied by the total hardware and software estimates
should be sufficient.

Mission MCA

94

Mission MCA

Training will include instructor-led classes in five different locations. The project team
believes it will be best to outsource most of the training, including developing course
materials, holding the sessions, and providing help desk support for three months as the
surveyors start using their devices in the field.
Because there are several risks related to this project, include 20 percent of the total
estimate as reserves.
You must develop a computer 1w )del for the estimate, making it easy to change several
inputs, such as the number of labor hours for various activities or labor rates.
Fortunately, the project team can easily access cost estimates and actual information from
similar projects. There is a great deal of information available front the proof of concept
project, and the team can also talk to contractor personnel from the past project to help
them develop the estimate. There are also some computer models available, such as a
software-estimating tool based on function points. Since the estimate must he provided by
WES and by month, the team first reviews a draft of the project schedule and makes further
assumptions, as needed. They decide first to estimate the cost of each WBS item and then
determine when the work will be performed, even though costs may be incurred at
different times than the work is performed. Their budget expert has approved this approach
for the estimate. Below are further assumptions and information for estimating the costs for
each WBS category:
1. Project management:
Estimate based on compensation for the part-time project manager and 25 percent of team
members' time. The budget expert for this project suggested using a labor rate of
8100/hour for the project manager and 875/hour for each team member, based on working
an average of 160 hours per summit full time. Therefore, the total hours Mr the project
manager under this category are 960 (160/2 * 12 = 960). Costs are also included for the our
project team members working 25 percent of their time each, or, a total of 160 hours per
month for all project personnel (160 * 12 = 1920). An additional amount will be added for all
contracted labor, estimated by multiplying 10 percent of their total estimates for software
development and testing costs (10%* ($594,000 + $69,000)).
2. Hardware
2.1 Handheld devices: 100 devices estimated by contractor at $600 per unit.
2.2 Servers: Four servers estimated at 84,000 each, based on recent server purchases. 268
3. Software
3.1 Licensed software: License costs will be negotiated with each supplier. Since there is a
strong probability of large future contracts and great publicity if the system works well,
costs are expected to be lower than usual. A cost of 8200/handheld device will be used.
3.2 Software development: This estimate will use two approaches:
alabor estimate and a function point estimate. The higher estimate will be used. lithe
estimates are more than 20 percent apart, a third approach to providing the estimate will
Mission MCA

95

Mission MCA

be required. The supplier who did the develop-mention the proof of concept project will
provide the labor estimate input. and local technical experts will make the function point
estimates.
4 Testing:
Based on similar projects, testing \yin be estimated as 10 percent of the total hardware and
software cost.
5 Training and support:
Based on similar projects, training will be estimated on a per-trainee basis, plus travel costs.
The cost per trainee (100 total) will he S500, and travel will be S700/day/person for the
instructors and project team members. It is estimated that there will be a total of 12 travel
days. Labor costs For the project tea In members will be added to this estimate to assist in
training and providing support after the training. The laborhours estimate for team
members is 1,920 hours total.
6. Reserves:
As directed, reserves will be estimated at 20 percent of the total estimate.

4.4.3 Cost Budgeting

The project schedule and budget may require several iterations before it is acceptableto the
sponsor, the project manager, and the project team. In addition, it isimportant that the
project manager document any and all assumptions used to comeup with duration and cost
estimates. For example, this documentation may includeestimating the salary of a database
administrator (DBA) who will be hired at afuture date. Instead of allocating a cost of what
the project manager thinks a DBAwill cost (or worse yet, what upper management would
like to pay), he or she coulduse salary surveys or salary information advertised in classified
advertisements asa base cost estimate. So, the project manager should document the
source of thiscost in order to give the cost estimates greater credibility.
In addition, the projectplan may include several working drafts. Having assumptions
documented can helpkeep things organized as well.Once the project schedule and project
plan are accepted, the project planbecomes the baseline plan that will be used as a
yardstick, or benchmark, to trackthe project's actual progress with the original plan. Once
accepted, the project managerand project team have the authority to execute or carry out
the plan. As tasksand activities are completed, the project plan must be updated in order to
communicatethe project's progress in relation to the baseline plan. Any changes or
revisionsto the project's estimates should be approved and then reflected in the plan
tokeep it updated and realistic.

Mission MCA

96

Mission MCA

4.5 Cost Control

Almost all the projects needs to be guided right through out, in order to receive the
required and expected output at the end of the project. It is the team that is responsible for
the project and most importantly the project manager that need to be able to carry out
effective controlling of the costs. There are however several techniques that can be used for
this purpose.
In addition to the project goals that the project manager has to oversee, the control of
various costs is also a very important task for any project. Project management would not
be effective at all if a project manger fails in this respect, as it would essentially determine
whether or not your organization would make a profit or loss.

4.5.1 Earned Value Management

Earned value management (EWA) is a project performance measurement technique. that
integrates scope, rime, and cost data_ Given a cost performance baseline, project managers
and their teams can determine how well the project is meeting scope, time, and cast goals
by entering actual information and then comparing it to the baseline. A baseline is the
original project plan plus approved changes. Actual information includes whether or lint a
VMS item was completed or approximately how much of the work wok; completed, when
the work actually started and ended, and 'how much it actually cost to do the
completed
work.
In the past, earned value management was used primarily on large government projects.
Today, however, more and more companies are realizing the value of using this tool to help
control costs. In fact, a discussion by several academic experts in earned value management
arid a real practitioner revealed the need to clarify how to actually calculate earned value.
Brenda Taylor, a senior project manager for P2 Project Management Solutions in
Johannesburg, South Africa, questioned calculating earned value by simply multiplying the
planned value to date by a percentage complete value_ She suggested using the rate of
performance instead, L5 described below
Earned value management involves calculating three values for each activity Or summary
activity from a project's VMS.
1. The planned value (P.F), also called the budget, is that portion of the 4ipproNred total
cost estimate planned to be spent on an activity during ;..1 given period. Table 7-.3 shows
an example of earned value calculations. Suppose a project include a summary activity of
purchasing and installing a new web server. Suppose further that, according to the plan, it
would take one week and cost a total of l0,000 for the labor hours, hardware, and software
involved. The planned value (TV) for that activity that week is, therefore, $10,000.
2.The actual cost (AC) is the total direct. and indirect costs incurred in accomplishing work
on [to activity during a given period. For example, suppose it actually took two weeks and
cost S201000 to purchase and install the new Web server. Assume that Sl5,000 of these
actual costs were incurred during Week 1 and 85,000 WAS incurred during Week 2. These
amounts are the actual cost (AC) for die activity each week.
Mission MCA

97

Mission MCA

3.Thu earned value (EV) is an estimate of the value of the physical work actually completed.
It is based on the original planned costs for die project or activity 4Lr1d die rate at which the
team is completing work on the project or activity to date, The rate of performance (RP) is
the ratio of actual work completed to the percentage of work planned to have been
completed at any given time during the life of the Project or activity.
For example, suppose the server installation was halfway completed by die end of Week 1.
The rate of performance would be50 percent (50/100) because by the end of Week I, the
planned schedule reflects that the task should be 100 percent complete and only 50 percent
of that work has been completed. In Table 7-4, the earned value estimate after one week is
therefore $5,000.14

The earned value calculations Table-4 are carried ou as folows:

EV = 10,000 * 50% = 5,000
C = 5,000 - 15,000 = -10,000
SV = 5,000 - 10,000 = -5,000
CPI = 5,000 / 15,000 = 33%
SPI = 5,000 / 10,000 = 50%
Table 7-5 summarizes the formulas used in earned value management. Note that the
formulas for variance and indexes starts with EV, the earned value. Variances are calculated
by subtracting the actual cost or planned value from EV, and indexes are calculated by

Mission MCA

98

Mission MCA

dividing EV by the actual cost or planned value. After you total the EN', AC, and IT data for
all activities on a project, you can use the CPI and SPI to project how much it will cost and
how long it will take to finish the project based on performance to date.
Given the budget at completion and original time estimate, you can divide by the
appropriate index to calculate the estimate at completion (EAC) and estimated time to
complete, assuming performance remains the same. There are no standard acronyms for
the term estimated time to complete or original time estimate.
Cost variance (CV) is the earned value minus the actual cost. If cost variance is a negative
number.it means that performing the work cost more than planned. If cost variance is a
positive numbe.it means that performing the work cost less than planned.
Schedule variance (SV) is the earned value minus the planned value. A negative schedule
variance means that it took longer than planned to perform the work, and a positive
schedule variance means that it took less time than planned to perform the work.
The cost performance index (CPI) is the ratio of earned value to actual cost and can be used
to estimate the projected cost of completing the project. If the cost performance index is
equal to one, or 100 percent, then the planned and actual costs are equalthe costs are
exactly as budgeted. If the cost performance index is less than one or less than 100 per-cent,
the project is over budget. If the cost performance index is greater than one or more than
100 percent, the project is under budget.
The schedule performance index (SPI) is the ratio of earned value to planned value and can
be used to estimate the projected time to complete the project. Similar to the cost
performance index, a schedule performance index of one, or 100 percent, means the
project is on schedule. If the schedule performance index is greater than one or 100
percent, then the project is ahead of schedule. If the schedule performance index is less
than one or 100 percent, the project is behind schedule.

Mission MCA

99

Mission MCA

Note that in general, negative numbers for cost and schedule variance indicate problems in
those areas. Negative numbers mean the project is costing more than planned or taking
longer than planned. Likewise, CP/and Si)! less than one or less than 100 percent also
indicate problems.
The cost performance index can be used to calculate the estimate at completion (EAC)an
estimate of what it will cost to complete the project based on performance to date.
Similarly, the schedule performance index can be used to calculate an estimated time to
complete the project.
You can graph earned value information to track project performance. Figure 7-5 shows an
earned value chart for a one-year project after five months. Note that the actual cost and
earned value lines end at five months, since that is the point in time where the data is
collected or estimated. The chart includes three lines and two points, as follows:
Planned value (PV), the cumulative planned amounts for all activities by month. Note that
the planned value line extends for the estimated length of the project and ends at the BAC
point.
Actual cost (AC), the cumulative actual amounts for all activities by month.
Earned value (EV), the cumulative earned value amounts for all activities by in month.
Budget at completion (BAC), the original total budget or the project, or S 100,000 in this
example. The BAC point is plotted on the chart at the original time estimate of 12 months.
Estimate at completion (EAC), estimated to be $122,308, in this example. This number is
calculated by taking the BAC, or $100,000 in this ease, and dividing by the CM, which, in this
example, was 81.761 percent. This EAC point is plot-ted on the chart at the estimated time
to complete of 12.74 months. This number is calculated by taking the original time
estimate, or 12 months in this ease, and dividing by the SPI, which in this example was
94.203 percent.

Mission MCA

100

Mission MCA

Viewing earned value information in chart form helps you visualize how the project is
performing. For example, you can see the planned performance by looking at the planned
value line. It' the project goes as planned, it will finish in 12 months and cost $100,000.
Notice in the example in Figure 7-5 that the actual cost line is always right on or above the
earned value line. When the actual cost line is right on or above the earned value line, costs
are equal to or more than planned. The planned value line is pretty close to the earned
value line, just slightly higher in the last month. This relationship means that the project has
been right on schedule until the last month, when the project fell behind schedule.
4.5.2 Project Portfolio Management
In many organizations, project managers also support an emerging business strategy
ofproject portfolio management(also called just portfolio managementin this text), inwhich
organizations group and manage projects and programs as a portfolio of investmentsthat
contribute to the entire enterprise s success. Portfolio managers help their organizations
make wise investment decisions by helping to select and analyze projects from a strategic
perspective. Portfolio managers may or may not have previous experience as projector
program managers. It is most important that they have strong financial and analyticalskills
and understand how projects and programs can contribute to meeting strategic goals.Figure
1-3 illustrates the differences between project management and project
portfoliomanagement. Notice that the main distinction is a focus on meeting tactical or
strategicgoals.
Tactical goals are generally more specific and short-term than strategic goals,
whichemphasize long-term goals for an organization. Individual projects often address
tacticalgoals, whereas portfolio management addresses strategic goals. Project
managementaddresses questions like Are we carrying out projects well? , Are projects on
time andbudget? , and Do project stakeholders know what they should be doing?Portfolio
Mission MCA

101

Mission MCA

management addresses questions like Are we working on the right projects? , Are we
investing in the right areas? , and Do we have the right resources to becompetitive? Pacific
Edge Software s product manager, Eric Burke, defines project portfolio management as the
continuous process of selecting and managing the optimum setof project initiatives that
deliver maximum business value.

Many organizations use a more disciplined approach to portfolio management by

developing guidelines and software tools to assist in project portfolio management. The
ProjectManagement Institute (described later in this chapter) first published the
OrganizationalProject Management Maturity Model (OPM3) Knowledge Foundation in
2003,19 whichdescribes the importance not only of managing individual projects or
programs well, but theimportance of following organizational project management to align
projects, programs, andportfolios with strategic goals. OPM3 is a standard that
organizations can use to measuretheir organizational project management maturity against
a comprehensive set of bestpractices.As you can imagine, project portfolio management is
not an easy task. Figure 1-4 illustrates one approach for project portfolio management
where one large portfolio exists forthe entire organization. This allows top management to
view and manage all projects atan enterprise level. Sections of that portfolio are then
broken down to improve themanagement of projects in each sector. For example, a
company might have the main

portfolio categories as shown in the left part of Figure 1-4 marketing, materials, IT,
andhuman resources (HR) and divide each of those categories further to address their
Mission MCA

102

Mission MCA

uniqueconcerns. The right part of this figure shows how the IT projects could be categorized
inmore detail to assist in their management. In this example, there are three basic IT project
portfolio categories:
Venture: Projects in this category help transform the business. For example,the large retail
chain described in the opening case might have an IT projectto provide kiosks in stores and
similar functionality on the Internet where customers and suppliers could quickly provide
feedback on products or services.This project could help transform the business by
developing closer partnerships with customers and suppliers.Growth: Projects in this
category would help the company grow in termsof revenues. For example, a company might
have an IT project to provide information on their corporate Web site in a new language,
such as Chinese or Japanese. This capability could help them grow their business in those
countries.Core: Projects in this category must be accomplished to run the business.
Forexample, an IT project to provide computers for new employees would fallunder this
category.
Note on the right part of Figure 1-4 that the Core category of IT projects is labeled
asnondiscretionary costs. This means that the company has no choice in whether to
fundthese projects; they must fund them to stay in business. Projects that fall under the
Ventureor Growth category are discretionary costs because the company can use its own
discretionor judgment in deciding whether or not to fund them. Notice the arrow in the
center of Figure 1-4 labeled Risks, Value/Timing. This arrow indicates that the risks, value,
and timingof projects normally increase as you move from Core to Growth to Venture
projects. However, some core projects can also be high risk, have high value, and require
good timing.As you can see, many factors are involved in portfolio management.Many
organizations use specialized software to organize and analyze all types of projectdata into
project portfolios. Enterprise or portfolio project management software integrates
information from multiple projects to show the status of active, approved, and
futureprojects across an entire organization. For example, Figure 1-5 provides a sample
screenfrom portfolio management software provided by Planview. The charts and text in
theupper half of the screen show the number and percentage of projects in this project
portfolio that are on target and in trouble in terms of schedule and cost variance. The
bottom halfof the screen lists the names of individual projects, percent complete, schedule
variance,cost variance, budget variance, and risk percentage. The last section in this chapter
provides more information on project management software.

Mission MCA

103

Mission MCA

FIGURE 1-5 Sample project portfolio management screen showing project health

Mission MCA

104

Mission MCA

Unit V : Project Quality and Communication Management

5.1 Tools and Techniques for Quality Control
Quality control includes many general tools and techniques. This section describes the
Seven Basic Tools of Quality, statistical sampling. and Six Sigmaand discusses how they
can be applied to information technology projects. The section concludes with a discussion
on testing. since information technology projects use testing extensively to ensure quality.
The following seven tools are known as the Seven Basic Tools of Quality:
1. Cause-and-effect diagrams: Cause-and-effect diagrams trace complaints about quality
problems back to the responsible production operations. In other words.they help you find
the root cause of a problem. They are also known as fishbone or Ishikawa diagrams, named
after their creator, kauru Ishikawa. You can also use the technique known as the 5 whys.
where you repeatedly ask the question "Why?" (five is a good rule of thumb) to help peel
away the layers of symptoms that can lead to the root cause of a problem. These symptoms
can be branches on the cause-and-effect diagram.
Figure 8-2 provides an example of a cause-and-effect diagram that Scott Daniels, the
consultant in the opening case, might create to uncover the root cause of the problem of
users not being able to log in to the EIS. Notice that it resembles the skeleton of a fish,
hence the name fishbone diagram. This fishbone diagram lists the main areas that could be
the cause of the problem: the EIS system's hardware, the user's hardware or software, or
the user's
training. This figure describes two of these areas, the individual user's hardware and
training, in more detail. For example, using the 5 whys, you could first ask why the users
cannot get into the system, then why they keep forgetting their passwords, why they did
not reset their passwords, why they did not check a box to save a password, and so on. The
root cause of the problem would have a significant impact on the actions taken to solve the
problem. If many users could not get into the system because their computers did not have
enough memory, the solution might be to upgrade memory for those computers. If many
users could not get into the system because they forgot their passwords, there might be a
much quicker, less expensive solution.

Mission MCA

105

Mission MCA

2. Control charts: A control chart is a graphic display of data that illustrates the results of a
process over time. Control charts : allow you to determine whether a process is in control or
out of control. When a process is in control, any variations in the results of the process are
created by random events. Processes that are in control do not need to be adjusted. When a
process is out of control, variations in the results of the process are caused by non random
events. When a process is out of control, you need to identify the causes of those non
random events and adjust the process to correct or eliminate them. For example, Figure 8-3
provides an example of a control chart for a process that manufactures 12-inch rulers.
Assume that these are wooden rulers created by machines on an assembly line. Each point
on the chart represents a length measurement for a ruler that comes off the assembly line.
The scale on the vertical axis goes from 11.90 to 12.10. These numbers represent the lower
and upper specification limits for die ruler. In this ease, this would mean that the customer
for the rulers has specified that all rulers purchased must be between 11.90 and 12.10
inches long, or 12 inches plus or minus 0.10 inches. The lower and upper control limits on
the quality control chart arc 11.91 and 12.09 inches, respectively.
This means the manufacturing process is designed to produce rulers between 11.91 and
12.09 inches long. Looking for and analyzing patterns in process data is an important part of
quality control. You can use quality control charts and the seven run rule to look for
patterns in data. The seven run rule states that if seven data points in a row are all below
the mean, 302 above die 11lentl, or are all increasing or decreasing, then the process needs
to be examined for non-random problems. In Figure 8-3, data points that violate the seven
run rule are starred. Note that you include the first point in a series of points that are all
increasing or decreasing. In the ruler manufacturing process, these data points may indicate
that a calibration device may need adjustment. For example, the machine that CUES the
Mission MCA

106

Mission MCA

wood for the rulers might need to be adjusted or the blade on the machine might need to
be replaced.

3. Run Chart: A run chart displays the history and pattern of variation of a pro-cess over
time. It is a line chart that shows data points plotted in the order in which they occur. You
can use run charts to perform trend analysis to forecast future outcomes based on historical
results. For example, trend analysis can help you analyze how many defects have been
identified over time and see if there are trends. Figure 8-4 shows a sample run chart,
charring the number of defects each month for three different types of defects. Notice that
you can easily see the patterns of Defect 1 continuing to increase over time. Defect 2
decreasing the first several months and then holding steady, and Defect
fluctuating each month.

Mission MCA

107

Mission MCA

Figure: 8- 4 Sample Run Chart

4. Scatter Diagram: A Scatter diagram helps to show if there is a relationship between two
variables. The closer data points are to a diagonal line, the more closely the two variables
are related. For example, Fig. 8-5 provides a sample scatter diagram that scott Daniels might
create to compare user satisfaction rating to the EIS system to the age of respondents to see
if there is a relationship. They might find that younger users are less satisfied with the
system, for example, and make decision based on that finding.

Figure 8-5 Sample scatter diagram

5. Histogram: A histogram is a bar graph of a distribution of variables. Each bar represents
an attribute or characterics of a problem or situation, and the height of the bar represents
its frequency. For example, Scott Dennis might ask the Help Desk to create a histogram to
show how many total complaints they received each week related to the EIS system. Figure
8-6 a sample histogram

Mission MCA

108

Mission MCA

6. Pareto Chart: A Pareto chart is a histogram chart that can help you identify and prioritize
problem areas. The variables described by the histogram are ordered by frequency of
occurrence. Pareto chart help you identify the vital few contributors that account for most
quality problem in a system.

7. Flowchart: Flowchart are graphic displays of the logic and flow of processes that help you
analyze how problems occur and how processes can be improved.
They show activities, decision points, and the ordered of how information is processed.
Figure 8-8 provides a simple example of a flowchart that shows the process a project team
might use for accepting or rejecting deliverables.

Figure 8-8 Sample Flowchart

Mission MCA

109

Mission MCA

5.2 Pareto Analysis

Another useful tool is a Pareto diagram, which was developed by Alfred Pareto(1848-1923).
Pareto studied the distribution of wealth in Europe and found that about80 percent of the
wealth was owned by 20 percent of the population. This idea hasheld in many different
settings and has become known as the 80/20 rule. For example,80 percent of the problems
can be attributed to 20 percent of the causes.Pareto diagrams can be constructed by
(Besterfield, Besterfield-Michna et al. 1999):
1. Determining how the data will be classified. It can be done by the nature ofthe problem,
the cause, non-conformity, or defect or bug.
2. Determining whether frequency, dollar amount, or both should be used torank the
classifications.
3. Collecting the data for an appropriate time period.
4. Summarizing the data by rank order of the classifications from largest tosmallest, from
left to right.
Pareto diagrams are useful for identifying and investigating the most importantproblems by
ranking problems in descending order from left to right. For example,let's say that we have
tracked all the calls to a call center over a period of one week. Ifwe were to classify the
different types of problems and graph the frequency of each typeof call, we would end up
with a chart similar to Figure 10.5.As you can see, the most frequent type of problem had to
do with documentationquestions. In terms of quality improvement, it may suggest that the
user documentationneeds to be updated.
In addition, flow charts can be useful for documenting a specific process in orderto
understand how products or services move through various functions or operations.A flow
chart can help visualize a particular process and identify potential problems orbottlenecks.
Standardized symbols can be used, but are not necessary. It is moreimportant to be able to
identify problems or bottlenecks, reduce complexity, anddetermine who is the next
customer (Besterfield, Besterfield-Michna et al. 1999).Figure 10.6, for example, documents
the projectmanagement process for verifying a project'sscope. The original customer who
initiates theoriginal project request might be the project'sclient or sponsor. The customer
who receives theoutput of the scope verification process might bea specific member of the
project team.

5.2.1 Statistical Sampling

Statistical Sampling Statistical sampling is a key concept in project quality management.
Members of a project team who focus on quality control must have a strong understanding
of statistics, but other project team members need to understand only the basic concepts.
These concepts include statistical sampling, certainty factor, standard deviation, and
variability. Standard deviation and variability are fundamental concepts for understanding
quality control charts. This section briefly describes these concepts and describes how a
project manager might apply them to in technology projects. Refer to statistics texts for
additional details.
Mission MCA

110

Mission MCA

Statistical sampling involves choosing part of a population

population of interest for inspection. For
example, suppose a company wants to develop an electronic data interchange (EDI) sys-tem
sys
for handling data on invoices from all of its suppliers. Assume also that in the past year, the
total mint her of invoices was 50,000 (nail 200 different suppliers. It would be very time
consuming and expensive to review every single invoice to determine data requirements for
the new system. Even if the system developers did review all 200 invoice forms from the
different suppliers,
s, the data might be entered differently on every form. It is impractical to
study every member of a population, such as all 50,000 invoices, so statisticians have
developed techniques to help determine an appropriate sample size. If the system
developers used statistical techniques, they might find that he studying only 100 invoices,
they would have a good sample of the type of data they would need in designing the
system.
The size of the sample depends on how representative you want the sample to be. A simple
formula for determining sample size is:
Sample size = .25 * (certainty factor/acceptable error)2
The certainty factor denotes how certain you want to be that the data sampled will not
include variations that do not naturally exist in the population.
population. You calculate the certainty
factor in an tables available in statistics books. Table 8-1
8 1 shows some commonly used
certainty factors.

For example, suppose the developer of the EDI system described earlier would accept 95
percent certainty that a sample
ple of invoices would contain no variation unless it was present
in the population of total invoices. They would then calculate the sample size as:
Sample size=0.25*(1.960 / .05)2 = 384
if the developers wanted 90 per cent certainty, they would calculate
calculate the sample size a s:
Sample size = 0.25*(13645/.10)2 = 68
if the developers wanted 80 per cent certainty, they would calculate the sample size as:
Sample size = 0.25*(1.281/.20)2 = 10
Assume the developers decide on 90 percent for the certainty factor.
factor. Then they would need
to examine 68 invoices to determine the type of the data the EDI system would to capture.

Mission MCA

111

Mission MCA

5.3 Six Sigma

The term Six Sigma was originated by Motorola (Schaumburg, Illinois) in themid-1980s. The
concept of Six Sigma came about as a result of competitive pressuresby foreign firms that
were able to produce higher quality products at a lower cost thanMotorola. Even Motorola's
own management at that time admitted that "our qualitystinks" (Pyzdek 1999).
Sigma (a) is a Greek letter and in statistics represents the standard deviation tomeasure
variability from the mean or average. In organizations, variation is often thecause of defects
or out-of-control processes and translates into products or servicesthat do not meet
customer needs or expectations. If a manufacturing process follows anormal distribution,
then the mean or average and the standard deviation can be usedto provide probabilities
for how the process can or should perform.Six Sigma focuses on defects per opportunities
(DPO) as a basis for measuringthe quality of a process rather than products it produces,
because products may vary incomplexity. A defect may be thought of as anything that
results in customer dissatisfaction.The sigma value, therefore, tells us how often defects are
likely to occur.
The higher the value of sigma, the lower the probability of a defect occurring. Asillustrated
in Table 10.1, a value of six sigma indicates that there will only be 3.4defects per million,
while three sigma quality translates to 66,807 defects per million.Table 10.2 provides
several real-world examples that compare the differencesbetween three sigma and six
sigma quality.Therefore, Six Sigma can be viewed as a quality objective whereby customer
satisfactionwill increase as a result of reducing defects; however, it is also abusiness-driven
approach for improving processes, reducing costs, and increasingprofits. The key steps in
the Six Sigma improvement framework are the D-M-A-I-Ccycle:
DefineThe first step is to define customer satisfaction goals and sub goal for example,
reduce cycle time, costs, or defects. These goals thenprovide a baseline or benchmark for
the process improvement.
MeasureThe Six Sigma team is responsible for identifying a set of relevant metrics.
AnalyzeWith data in hand, the team can analyze the data for trends, patterns, or
relationships. Statistical analysis allows for testing hypotheses,modeling, or conducting
experiments.
ImproveBased on solid evidence, improvements can be proposed andimplemented. The
Measure - Analyze - Improve steps are generally iterative to achieve target levels of
performance.
ControlOnce target levels of performance are achieved, control methodsand tools are
put into place in order to maintain performance.To carry out a Six Sigma program in an
organization, a significant investment intraining and infrastructure may be required.
Motorola adopted the following martialarts terminology to describe these various roles and
responsibilities (Pyzdek 1999):

Mission MCA

112

Mission MCA

5.4 Quality
What is quality? Before answering that question, keep in mind that quality can
meandifferent things to different people. For example, if we were comparing the quality
oftwo carsan expensive luxury car with leather seats and every possible option to alowerpriced economy car that basically gets you where you want to gomany peoplemay be
inclined to say that the more expensive car has higher quality. Although themore expensive
car has more features, you may not consider it a bargain if you have tokeep bringing it back
to the shop for expensive repairs. The less-expensive car may startlooking much better to
you if it were more dependable or met higher safety standards.On the other hand, why do
car manufacturers build different models of cars withdifferent price ranges?
If everyone could afford luxury cars, then quality comparisonsamong different
manufacturers' cars would be much easier. Although you may haveyour eyes on a luxury
car, your current financial situation (and subsequent logic) maybe a constraint. You may
have to buy a car you can afford.Therefore, it is important not to define quality only in
terms of features or functionality.Other attributes such as dependability or safety may be
just as important tothe customer. Similarly in software development, we can build systems
that have agreat deal of functionality, but perform poorly.
On the other hand, we can develop systemsthat have few features or limited functionality,
but also fewer defects.However, we still need a working definition of quality. The dictionary
definesquality as "an inherent or distinguishing characteristic; a property," or as
something"having a high degree of excellence." In business, quality has been defined in
terms of"fitness for use" and "conformance to requirements." "Fitness for use"
concentrateson delivering a system that meets the customer's needs, while "conformance
torequirements" centers more on meeting some predefined set of standards.
Therefore,quality depends on the needs or expectations of the customer.
It is up to the projectmanager and project team to accurately define those needs or
expectations, whileallowing the customer to remain within his or her resource
constraints.Although the concepts and philosophies of quality have received a great deal
ofattention over the last fifty years in the manufacturing and service sectors, many ofthese
same ideas have been integrated into a relatively new discipline or knowledgearea called
project quality management (PQM). The Project Management Body ofKnowledge defines
PQM as:
The processes required to ensure that the project will satisfy theneeds for which it was
undertaken. It includes all activities of theoverall management function that determine the
quality policy,objectives, and responsibility and implements them by means ofquality
planning, quality assurance, quality control, and qualityimprovement, within the quality
system. (95)Moreover, PMBOK defines the major quality management processes as:
Quality PlanningDetermining which quality standards are important tothe project and
deciding how these standards will be met.
Quality AssuranceEvaluating overall project performance regularly toensure that the
project team is meeting the specified quality standards.
Mission MCA

113

Mission MCA

Quality ControlMonitoring the activities and results of the project toensure that the
project complies with the quality standards. In addition, theproject organization as a whole
should use this information to eliminatecauses of unsatisfactory performance and
implement new processes andtechniques to improve project quality throughout the project
organization.
Therefore, PQM should focus on both the product and process of the project.From our point
of view, the project's most important product is the information systemsolution that the
project team must deliver. The system must be "fit for use" and"conform to specified
requirements" outlined in both the project's scope and requirementsdefinition. More
importantly, the IT product must add measurable value to thesponsoring organization and
meet the scope, schedule, and budget objectives. Qualitycan, however, also be built into the
project management and software developmentprocesses. A process refers to the activities,
methods, materials, and measurementsused to produce the product or service.
We can also view these processes as part of aquality chain where outputs of one process
serve as inputs to other project managementprocesses (Besterfield, Besterfield-Michna et
al. 1999).By focusing on both the product and chain of project processes, the project
organizationcan use its resources more efficiently and effectively, minimize errors, and
meet or exceed project stakeholder expectations. The cost of quality, however, can
beviewed as the cost of conforming to standards (i.e., building quality into the productand
processes) as well as the cost of not conforming to the standards (i.e., rework).Substandard
levels of quality can be viewed as waste, errors, or the failure to meet theproject sponsor's
or client's needs, expectations, or system requirements(Kloppenborg and Petrick
2002).Failing to meet the quality requirements or standards can have negative
consequencesfor all project stakeholders and impact the other project objectives.
More specifically, adding additional work or repeating project activities will probably extend
the project schedule and expand the project budget. According to Barry Boehm (Boehm
1981), a software defect that takes one hour to fix when the systems requirements are
being defined will end up taking one hundred hours to correct if not discovered until the
system is in production. Moreover, poor quality can be an embarrassment for the project
manager, the project team, and the project organization. For example, one of the most
widely publicized software defect stories was the faulty baggage-handling software at the
Denver International Airport.
Bugs in the software delayed the opening of the airport from October 1993 to February
1995 at an estimated cost of $1,000,000 a day! Newspaper accounts reported that bags
were literally chewed up and contents of bags were flying through the air (Williamson
1997). The concepts and philosophies of quality management have received a great deal of
attention over the years. Although popularized by the Japanese, many organizations in
different countries have initiated quality improvement programs. Such programs include ISO
certification, six steps to Six Sigma initiatives, or awards such as the Deming Prize or the
Malcolm Baldridge National Quality Award. More recently, the Capability Maturity Model
(CMM) has provided a framework for software quality that focuses on assessing the process
maturity of software development within an organization. Based on writings and teachings
of such quality gurus as Shewhart, Deming, Juran, Ishikawa, and Crosby, the core values of
Mission MCA

114

Mission MCA

these quality programs have a central theme that includes a focus on the customer,
incremental or continuous improvement, problem detection and correction, measurement,
and the notion that prevention is less expensive than inspection.

A commitment to these quality initiatives, however, often requires a substantial cultural

change throughout the organization. In this chapter, you will learn how the concepts of
quality management can be applied to IT project management. We will also extend these
concepts to include a broader view of PQM in order to support the overall project goal and
objectives. As illustrated in Figure 10.1, PQM will not only include the concepts, teachings,
tools, and methods of quality management, but also validation/verification and change
control. Verification and validation (V&V) activities within PQM should be carried out
throughout the project life cycle. They require the project team to continually ask, Are

we building the right product? Are we building the product the right way? Therefore, the
project quality plan should not only focus on final testing of the system at the end ofthe
project life cycle, but also on all project deliverables. Finding and fixing problems earlier in
the project life cycle is less costly than having to deal with them in the later stages of the
project. Finding problems early not only leads to less rework later, but also saves the project

Mission MCA

115

Mission MCA

manager and project team from having to deal with embarrassing issues and problems once
the project's product is in the hands of the project sponsor or end-customer.
In addition, software development often requires a number of people to work on multiversions of documents, programs, and database files that are shared and distributed among
various project stakeholders. Change control in the form of configuration management,
therefore, is a method of code and document management to track and organize the
different versions of documents and files. It keeps the project team more focused and
reduces the likelihood of errors. In addition, knowledge management and the lessons
learned can be implemented as best practices and incorporated in projects throughout the
organization.
Such changes lead to both continuous improvement and to a maturing of IT project
management processes. Taken together, the concepts of quality management, V&V
activities, change control, and knowledge management support the overall PQM plan. The
plan not only helps improve the overall quality of the project's product and processes, but
can also lead to a competitive advantage for the project organization because the project
will have a greater likelihood of achieving its expected organizational value and support the
scope, schedule, and budget objectives.
The remainder of this chapter will focus on introducing and delving into several PQM
concepts. It includes an overview of the quality movement and a brief history of the people
who provided the cornerstones for quality initiatives. It also provides an overview of several
quality systems. Finally, it gives a framework to support PQM that integrates the concepts
and philosophies of quality, as well as the concepts of software testing, configuration
management, and knowledge management.

5.5 Control Charts and the seven Run Rule

A Control Chart is a graphic display of data that illustrates the results of a process over time.
Control charts allow you to determine whether a process is in control or out of control.
When a process is in control, any variations in the results of the process are created by
random events. Processes that are in control do not need to be adjusted. When a process is
out of control, variations in the results of the process are caused by non random events.
When a process is out of control, you need to identify the causes of those non random
events and adjust the process to correct or eliminate them. For example, Figure 8-3
provides an example of a control chart for a process that manufactures 12-inch rulers.
Assume that these are wooden rulers created by machines on an assembly line. Each point
on the chart represents a length measurement for a ruler that comes off the assembly line.
The scale on the vertical axis goes from 11.90 to 12.10. These numbers represent the lower
and upper specification limits for die ruler. In this ease, this would mean that the customer
for the rulers has specified that all rulers purchased must be between 11.90 and 12.10
inches long, or 12 inches plus or minus 0.10 inches. The lower and upper control limits on
the quality control chart arc 11.91 and 12.09 inches, respectively.

Mission MCA

116

Mission MCA

This means the manufacturing process is designed to produce rulers between 11.91 and
12.09 inches long. Looking for and analyzing patterns in process data is an important part of
quality control. You can use quality control charts and the seven run rule to look for
patterns in data.
The seven run rule states that if seven data points in a row are all below the mean, 302
above die 11lentl, or are all increasing or decreasing, then the process needs to be
examined for non-random problems. In Figure 8-3, data points that violate the seven run
rule are starred. Note that you include the first point in a series of points that are all
increasing or decreasing. In the ruler manufacturing process, these data points may indicate
that a calibration device may need adjustment. For example, the machine that CUES the
wood for the rulers might need to be adjusted or the blade on the machine might need to
be replaced.

5.6 Modern Quality management

Modern quality management requires customer satisfaction, prefers prevention to
inspection, and recognizes management responsibility for quality. Several noteworthy
people helped develop the following theories, tools, and techniques that define modern
quality management. The suggestions from these quality experts led to many projects to
improve quality and provided the foundation for today's Six Sigma projects. This section
summarizes major contributions made by Deming, loran. Crosby, Ishikawa, Taguchi, and
Feigenbaum.
Deming and His 14 Points for Management Dr. W. Edwards Deming is known primarily for
his work on quality control in Japan. Dr. Deming went to Japan after World War II, at the
request of the Japanese government, to assist them in improving productivity and quality.
Mission MCA

117

Mission MCA

Deming, a statistician and former professor at New York University, taught Japanese
manufacturers that higher quality meant greater productivity and lower cost. American
industry did in recognize Deming's theories until Japanese manufacturers started producing
products that seriously challenged American products, particularly in the auto industry. Ford
Motor Company then adopted Deming's quality methods and experienced dramatic
improvement in quality and sales thereafter. By the 1980s, after seeing the excellent work
corning out of Japan, several U.S. corporations vied for Deming's expertise to help them
establish quality improvement programs in their own factories. Many people are familiar
with the Deming Prize, an award given to recognize high-quality organizations, and Deming's
Cycle for Improvement: plan, do, check, and act. Most Six Sigma principles described earlier
are based on the plan-do-cheek-act model created by Deming. Many are also familiar with
Deming's 14 Points for Management, summarized below from Deming's text Out of the
Crisis:
1. Create constancy of purpose for improvement of product and service.
2. Adopt the new philosophy.
3. Cease dependence on inspection to achieve quality.
4. End the practice of awarding business based on price tag alone. Instead, minimize total
cost by working with a single supplier.
5. Improve constantly and forever every process for planning, production, and service.
6. Institute training on the job.
amounts of money on improving quality. Crosby developed the following 14 steps for
quality improvement:
1. Make it clear that management is committed to quality.
2. Form quality improvement teams with representatives from each department.
3. Determine where current and potential quality problems lie.
4. Evaluate the cost of quality and explain its use as a management tool.
5. Raise the quality awareness and personal concern of all employees.
6. Take actions to correct problems identified through previous steps.
7. Establish a committee for the zero-defects program.
8. Train supervisors to actively carry out their part of the quality improvement program.
9. Hold a "zero-defects day" to let all employees realize that there has been a change.
10. Encourage individuals to establish improvement goals for themselves and their groups.
11. Encourage employees to communicate to management the obstacles they face in
attaining their improvement goals.
12. Recognize and appreciate those who participate.
13. Establish quality councils to communicate on a regular basis.
14. Do it all over again to emphasize that the quality improvement program never ends.
Crosby also developed the Quality Management Process Maturity Grid in 1978. This grid can
he applied to an organization's attitude toward product usability. For example, the first
stage in the grid is ignorance, where people might think they don't have any problems with
usability. The final stage is wisdom, where people have changed their attitude so that
usability defect prevention is a routine part of their operation.

Mission MCA

118

Mission MCA

5.6.1 Juran and the importance of Top management

Joseph Juran's philosophies and teachings have also had an important and significant impact
on many organizations worldwide. Like Deming, Juran started out as an engineer in the
1920s. In 1951 he published the Quality Control Handbook, which viewed quality as "fitness
for use" as perceived by the customer. Like Deming, Juran was invited to Japan by JUSE in
the early 1950s to conduct seminars and lectures on quality.
Juran's message on quality focuses on his belief that quality does not happen by accident
it must be planned. In addition, Juran distinguishes external customers from internal
customers. Juran's view of quality consists of a quality trilogyquality planning, quality
control, and quality improvementthat can be combined with the steps that make up
Juran's Quality Planning Road Map.
Quality Planning
1. Identify who are the customers.
2. Determine the needs of those customers.
3. Translate those needs into our language.
4. Develop a product that can respond to those needs.
5. Optimize the product features so as to meet our needs as well as customer needs.
Quality Improvement
6. Develop a process that is able to produce the product.
7. Optimize the process.
Quality Control
8. Prove that the process can produce the product under operating conditions.
9. Transfer the process to Operations.

5.6.2 commitment to Quality

Joseph M. Juran. like Denting, (aught Japanese manufacturers how to improve their
productivity. ALS.companies later discovered him as well. Ile wrote the first edition of the
Quality Control I landbook in 1974, stressing the importance of top management
commitment to continuous product quality improvement. In 2000, at the age of 94, Junin
published the fifth edition of this fatuous handbook." Ile also developed theJunin Trilogy:
quality improvement, quality planning. and quality control. Aural' stressed the difference
between the manufacturer's view of quality and the customer's view. manufacturers often
focus on conformance to requirements, but customers it on fitness for use. Most definitions
of quality now use fitness for use to stress the importance of satisfying stated or implied
needs and not just meeting stated requirements or specificationsJuran developed 10 step to
quality improvement

Mission MCA

119

Mission MCA

1. Build awareness of the need and opportunity for improvement.

2. Set goals for improvement.
3. Organize to reach the goals (establish a quality council, identify problems, select projects,
appoint teams, designate facilitators).
4. Provide training.
5. Carry out projects to solve problems.
6. Report progress.
7. Give recognition.
8. Communicate results.
9. Keep score.
10. Maintain momentum by making annual improvement part of the regular systems and
processes of the company.

5.6.3 Crosby and Striving for Zero defects

Like F.W. Taylor, Philip Crosby developed many of his ideas from his experiences working on
an assembly line. After serving in the Navy during the Korean War, he worked his way up in
a variety of quality control positions until he held the position of corporate vice president
and director of quality for ITT. In 1979, he published a best-selling book, Quality is Free, and
eventually left ITT to start his own consulting firm that focused on teaching other
organizations how to manage quality.

Crosby defined quality as conformance to requirements based on the customer's needs and
advocated a top-down approach to quality in which it is management's responsibility to set
a quality example for workers to follow. Crosby also advocated "doing it right the first time"
and "zero defects", which translate into the notions that quality is free and that nonconformance costs organizations money.

Crosby developed the following 14 steps for quality improvement:

1. Make it clear that management is committed to quality.
2. Form quality improvement teams with representatives from each department.
3. Determine where current and potential quality problems lie.
4. Evaluate the cost of quality and explain its use as a management tool.
5. Raise the quality awareness and personal concern of all employees.
6. Take actions to correct problems identified through previous steps.
7. Establish a committee for the zero-defects program.
8. Train supervisors to actively carry out their part of the quality improvement program.
9. Hold a "zero-defects day" to let all employees realize that there has been a change.
10. Encourage individuals to establish improvement goals for themselves and their groups.
11. Encourage employees to communicate to management the obstacles they face in
attaining their improvement goals.
12. Recognize and appreciate those who participate.
13. Establish quality councils to communicate on a regular basis.
Mission MCA

120

Mission MCA

14. Do it all over again to emphasize that the quality improvement program never ends.
Crosby also developed the Quality Management Process Maturity Grid in 1978. This grid can
he applied to an organization's attitude toward product usability. For example, the first
stage in the grid is ignorance, where people might think they don't have any problems with
usability. The final stage is wisdom, where people have changed their attitude so that
usability defect prevention is a routine part of their operation.

5.6.4 Ishikawa and the Fishbone Diagram

Kaoru Ishikawa studied under Deming and believes that quality improvement is a
continuous process that depends heavily on all levels of the organizationfrom top
management down to every worker performing the work. In Japan this belief led to the use
of quality circles that engaged all members of the organization. In addition to the use of
statistical methods for quality control, Ishikawa advocated the use of easy-to-use analytical
tools that included cause-and-effect diagrams (called the Ishikawa diagram, or fishbone
diagram, because it resembles the skeleton of a fish), the Pareto Chart, and flow charts.
Although the Ishikawa, or fishbone, diagram was introduced in an earlier chapter, it can be
used in a variety of situations to help understand various relationships between causes and
effects. An example of an Ishikawa diagram is illustrated in Figure 10.4.
The effect is the rightmost box and represents the problem or characteristic that requires
improvement. A project team could begin by identifying the major causes, such as people,
materials, management, equipment, measurements, and environment, that may influence
the problem or quality characteristic in question. Each major cause can then be subdivided
in potential sub-causes. For example, causesassociated with people may be lack of training
or responsibility in identifying and correcting a particular problem. An Ishikawa diagram can
be best developed by brain-storming or by using a learning cycle approach. Once the
diagram is complete, the project team can investigate the possible causes and recommend
solutions to correct the problems and improve the process.
Another useful tool is a Pareto diagram, which was developed by Alfred Pareto (1848-1923).
Pareto studied the distribution of wealth in Europe and found that about 80 percent of the
wealth was owned by 20 percent of the population. This idea has held in many different
settings and has become known as the 80/20 rule. For example, 80 percent of the problems
can be attributed to 20 percent of the causes.

Mission MCA

121

Mission MCA

Figure 10.4 Ishikawa, or Fishbone, Diagram

Pareto diagrams can be constructed by (Besterfield, Besterfield-Michna et al. 1999):
1. Determining how the data will be classified. It can be done by the nature of the problem,
the cause, non-conformity, or defect or bug.
2. Determining whether frequency, dollar amount, or both should be used to
rank the classifications.
3. Collecting the data for an appropriate time period.
4. Summarizing the data by rank order of the classifications from largest to smallest, from
left to right.
Pareto diagrams are useful for identifying and investigating the most important problems by
ranking problems in descending order from left to right. For example, let's say that we have
tracked all the calls to a call center over a period of one week. Ifwe were to classify the
different types of problems and graph the frequency of each type of call, we would end up
with a chart similar to Figure 10.5. As you can see, the most frequent type of problem had to
do with documentation questions.
In terms of quality improvement, it may suggest that the user documentation needs to be
updated. In addition, flow charts can be useful for documenting a specific process in order
to understand how products or services move through various functions or operations. A
flow chart can help visualize a particular process and identify potential problems or
bottlenecks. Standardized symbols can be used, but are not necessary. It is more important
to be able to identify problems or bottlenecks, reduce complexity, and determine who is the
next customer (Besterfield, Besterfield-Michna et al. 1999).Figure 10.6, for example,
documents the projectmanagement process for verifying a project'sscope. The original
customer who initiates theoriginal project request might be the project'sclient or sponsor.
Mission MCA

122

Mission MCA

The customer who receives theoutput of the scope verification process might bea specific
member of the project team.

Mission MCA

123

Mission MCA

5.6.5 Improving Information Technology Project Quality

In addition to some of the suggestions provided for using good quality planning, quality
assurance, and quality control, there are several other important issues involved in
improving, the quality of information technology projects. Strong leadership, understanding
t he cost of quality, providing a good workplace to enhance quality and working toward
improving the organization's overall maturity level in software development and project
management can all assist in improving quality.
Leadership
As Joseph M. loran said in 1945, "It is most important that top management he qualityminded. In the absence of sincere manifestation of interest at the top, little will happen
below."24Juran and many other quality experts argue that the main cause of quality
problems is a lack of leadership. As globalization continues to increase and customers
become more and more demanding, creating quality products quickly at a reasonable price
is essential for staying in business. having good quality programs in place helps
organizations remain competitive. To establish and implement effective quality programs,
top management must lead the way.
A large percentage of quality problems are associated with management, not technical
issues. Therefore, top management must take responsibility for creating, supporting, and
promoting quality programs. Motorola provides an excellent example of a high-technology
company that truly emphasizes quality. Leadership is one of the factors that helped
Motorola achieve its great success in quality management and Six Sigma. Top management
emphasized the need to improve quality and helped all employees take responsibility for
customer satisfaction. Strategic objectives in Motorola's long-range plans included
managing quality improvement in the same way that new products or technologies were
managed. Top management stressed the need to develop and use quality standards and
provided resources such as staff, training, and customer inputs to help improve quality.
Leadership provides an environment conducive to producing quality. Management must
publicly declare the company's philosophy and commitment to quality, implement
company-wide training programs in quality concepts and principles, implement
measurement programs to establish and track quality levels, and actively demonstrate the
importance of quality. When every employee understands and insists on producing highquality products, then top management has done a good job of promoting the importance
of quality.

The Cost of Quality

The cost of quality is the cost of conformance plus the cost of non conformance.
Conformance means delivering products that meet requirements and fitness for use.
Examples of these costs include the costs associated with developing a quality plan, costs
for and managing product requirements, and costs for testing. The cost of non conformance
means taking responsibility for failures or not meeting quality expectations. A 2002 study by
RTI International reported that software bugs cost the U.S. economy 859.6 billion each year,
Mission MCA

124

Mission MCA

about 0.6 percent of gross domestic product. Most of the costs are borne by software users,
and the rest by developers and vendors. RTI International also suggested that more than
01IC third of these costs could be eliminated by an improved testing infrastructure to enable
earlier and more effective identification and removal of software detects. Other studies
estimate the costs per hour of down time for systems. For example, Gartner estimated that
the hourly east of downtime for computer networks is about $42,000. There-fore, a
company that suffers from a worse-than-average downtime of 175 hours a year can lose
more than 87 million per year.26 The five major cost categories related to quality include:
1. Prevention cost: The cost of planning and executing a project so that it is error-free or
within an acceptable error range. Preventive actions such as training, detailed studies
related to quality, and quality surveys of suppliers and sub-contractors fall under this
category. Recall from the discussion of cost management (see Chapter 7) that detecting
defects in information systems during the early phases of the systems development life
cycle is much less expensive than during the later phases. One hundred dollars spent
refining user requirements could save millions by finding a defect before implementing a
large system. The Year 2000 ( Y2K) issue provided a good example of these costs. If
organizations had decided during the 1960s, 1970s, and 1980s that all dates would need
four characters to represent the year instead of two charac-ters. they would have saved
billions of dollars.
2. Appraisal cost: The cost of evaluating processes and their outputs to ensure that a
project is error-free or within an acceptable error range. Activities such as inspection and
testing of products, maintenance and equipment of test equipment, and processing, ancl
reporting inspection data all contribute to appraisal costs of quality.
such as easily making cell phone calls, using a train or subway instead of relying on a car for
transportation, or getting up-to-date maps. It's important to realize that different countries
are at different stages of development in terms of quality.
Maturity Models
Another approach to improving quality in software development projects and project
management in general is the use of maturity models, which are frameworks for helping
organizations improve their processes and systems. Maturity models describe an
evolutionary path of increasingly organized and systematically more mature processes.
Many maturity models have five levels, with the first level describing characteristics of the
least organized or mature organizations, and level five describing the characteristics of the
most organized and mature organizations. Three popular maturity models include the
Software Quality Function Deployment (SQFD) model, the Capability Maturity Model
Integration (CMMI), and the project management maturity model.

Mission MCA

125

Mission MCA

Software Quality Function Deployment Model

The Software Quality Function Deployment (SOFD) model is an adaptation of the quality
function deployment model suggested in 1986 as an implementation vehicle for Total
Quality Management (TQM). SQFD focuses on defining user requirements and planning
software projects. The result of SQFD is a set of measurable technical product specifications
and their priorities. I hiving clearer requirements can lead to fewer design changes,
increased productivity, and, ultimately, software products that are more likely to satisfy
stakeholder requirements. The idea of introducing quality early in the design stage was
based on Taguchi's emphasis on robust design methods:'
Capability Maturity Model Integration
Another popular maturity model is in continuous development at the Software Engineering
Institute at Carnegie Mellon University. The Software Engineering Institute (SEI) is a federally funded research and development center established in 1984 by the U.S. Department of
Defense with a broad mandate to address the transition of software engineering
technology. The Capability Maturity Model Integration (CMMI) is "a process improvement
approach that provides organizations with the essential elements of effective processes. It
can be used to guide process improvement across a project. a division, or an entire
organization. CMMI helps integrate traditionally separate organizational functions, set
process improvement goals and priorities, provide guidance for quality processes. and
provide a point of reference for appraising current processes." The capability levels of the
CMMI are:
0. Incomplete: At this level, a process is either not performed or partially per-formed.
No generic goals exist for this level, and one or more of the specific goals of the
process area are not satisfied. 1
1. Performed: A performed process satisfies the specific goals of the process area and
supports and enables the work needed to produce work products. Although this
capability level can result in improvements, those improvements can he lost over
time if they are not institutionalized.
2. Managed: At this level, a process has the basic infrastructure in place to sup-port it.
The process is planned and executed based on policies and employs skilled people
who have adequate resources to produce controlled outputs. The process discipline
reflected by this level ensures that existing practices are retained during times of
stress.
3. Defined: At this maturity level, a process is rigorously defined and the standards,
process descriptions, and procedures for a project are tailored from the
organization's set of standard processes to suit that particular project.
4. managed: At this level, a process is controlled using statistical and other quantitative
techniques. The organization establishes quantitative objectives for quality and
process performance that arc used as criteria in man-aging the process.
Mission MCA

126

Mission MCA

5. Optimizing: An optimizing process is Unproved based on an understanding of the

common causes of variation inherent in the process. The focus is on continually
improving the range of process performance through incremental and innovative
improvements.
Many companies that want to work in the government market have realized that they
will not get many opportunities even to bid on projects unless they have a CNDAI Level
3. According to one manager, "CM II is really the future. People who aren't cat the
bandwagon now are going to find themselves falling behind ."33
Project Management Maturity Models
In the late 1990s, several organizations began developing project management maturity
models based on the Capability Maturity Model. Just as organizations realized the need to
improve their software development processes and systems, they also realized the need to
enhance their project management processes and systems for all types of projects. The PMI
Standards Development Program published the Organizational Project Management
Maturity Model (OPM3) in December 2003, and the second edition was released in late
2008. More than 200 volunteers from around the world were part of the initial OPM3 team.
The model is based on market research surveys that had been sent to more than 30,000
project management professionals and incorporates 180 best practices and more than
2,400 capabilities, outcomes, and key performance indicators?" According to John
Schceiner, the OPM3 program director, "The standard would help organizations to assess
and improve their project management capabilities as well as the capabilities necessary to
achieve organizational strategies through projects. The standard would be a project
management maturity model, setting the standard for excellence in project, program, and
portfolio management best practices, and explaining the capabilities necessary to achieve
those best practices.

Mission MCA

127

Mission MCA

5.6.6 The Project Communication Plan

Communications is by far the most important driver in project management and more often
than not it is the least adequately planned part of the project and least effectively carried
out.
Communications planning involves planning for all the communications with project
stakeholders. A useful tool is the reporting schedule. It can help you identify the frequency
and types of information required by different stakeholders.
Stakeholder Reporting
needs
Sponsor

Format

Status
Spread
report
- sheet
for
including
schedule
schedule,
and budget
budget,
status,
variances,
table
for
issues
scope
status and
issues plus
a one page
summary

Preferred
medium
Email
attach. 24
hours prior
to face to
face
meeting

When

Person
responsible

Meeting
Project
last Mon. Manager
of
each
month
prior to
Board
meeting

Communication protocols include the:

method of communication

standards

templates

security

ethics

time frames and reporting schedules.

who requires the information

version control method

Communication can often be difficult. There can be misunderstandings; one way

communication; lack of verification; insufficient, inaccurate and inappropriate information;
information can be withheld and inappropriate communication media may be used.

5.6.7 Reporting Performance and Progress

Performance reporting keeps stakeholders informed about how resources are being used to
achieve project objectives. Work performance information and measurements, forecasted
completion dates, quality control measurements, the project management plan, approved
change requests, and deliverables are all important inputs to performance reporting. Two
Mission MCA

128

Mission MCA

key outputs of performance reporting are performance reports and forecasts. Performance
reports are normally provided as status reports or progress reports. Many people use the
two terms interchangeably. Inn mane people distinguish between them as follows:
Status reports describe where the project stands at a specific point in time. Recall the
importance of the triple constraint. Status reports address where the project stands in
terms of meeting scope. time, and cost goals. how much money has been spent to date?
lbw long did it take to do certain tasks? Is work being accomplished as planned? Status
reports can take various formats depending on the stakeholders' needs.
Progress reports describe what the project team has accomplished during a certain
period. Many projects have each team member prepare a monthly or sometimes weekly
progress report. Team leaders often create consolidated progress reports based on the
information received from team members. A sample template for a monthly progress report
is provided later in this chapter.
Forecasts predict future project status and progress based on past information and trends.
lbw long will it take to finish the project based on how things are going? How much more
money will be needed to complete the project? Project managers can also use earned value
management (see Chapter 7, Project Cost Management) to answer these questions
by estimating the budget at completion and projected completion date based on how the
project is progressing.
Another important technique for performance reporting is the status review meeting. Status
review meetings, as described in Chapter 4, Project Integration Management, are a good
way to highlight information provided in important project documents, empower people to
be accountable for their work, and have face-to-face discussions about important project
issues. Many program and project managers hold periodic status review meetings to
exchange important project information and motivate people to make progress on their
parts of the project.
Likewise, many top managers hold monthly or quarterly status review meetings where
program and project managers must report overall status information. Status review
meetings sometimes become battlegrounds where conflicts between different parties come
to a head. Project managers or higher-level top managers should set ground rules for status
review meetings to control the amount of conflict and should work to resolve any potential
problems. It is important to remember that project stack holders should work together to
address performance problems.

Mission MCA

129

Mission MCA

5.6.8 Information Distribution

Getting project information to the right people at the right time and in a useful format is
just as important as developing the information in the first place. The stakeholder
communications analysis serves as a good starting point for information distribution. Project
managers and their teams must decide who receives what information, but they must also
decide the best way to distribute the information. Is it sufficient to send written reports for
project information? Are meetings alone effective in distributing project information? Are
meetings and written communications both required for project information? What is the
best way to distribute information to virtual team members? During project execution,
project teams must address important considerations for information distribution, and they
often end up updating business processes through improved communications.
For example.they might modify policies and procedures, infor-niati011 systems, or
incorporate new technologies to improve information distribution. For example, Peter
Gunmen, the program manager in the opening case, might decide that providing key people
on his projects with handheld wireless devices, such as an iPhone or BlackBerry, would
enhance communications. Ile would need to request additional funds to provide these
devices and training on how to use them. After answering key questions related to project
communications, project managers and their teams must decide the best way to distribute
the information. Important considerations for information distribution include the use of
technology, formal and informal communications, and the complexity of communications.
Using Technology to Enhance Information Distribution Technology can facilitate the process
of distributing information, when used properly. Most people and businesses rely on e-mail,
instant messaging, Web sites, telephones, cell phones, and other technologies to
communicate. Using an internal project management information system, you can organize
project documents, meeting minutes, customer requests. and so on, and make them
available in an electronic format. Y(m can store this information in local software or make it
available on an Intranet, an extract, or the Internet, if the information is not sensitive.
Storing templates and samples of project documents electronically can make accessing
standard forms easier. thus making the information distribution process easier.
Formal and Informal Methods for Distributing Information
It is not enough for project team members to submit status reports to their project
managers and other stakeholders and assume that everyone who needs to know that
information will read the reports. Some technical professionals might assume that
submitting the appropriate status reports is sufficient because they are introverts and prefer
communicating that way. Occasionally, that approach might work, but many people prefer
informal communications. Recall front Chapter 9 that 75 percent of the general population
are extroverts, so they enjoy talking to other people. Often, many non-technical
professionalsfrom colleagues to managersprefer to have a two-way conversation about
Mission MCA

130

Mission MCA

project information, rather than reading detailed reports, e-mails, or Web pages to try to
find pertinent information. Instead of focusing on getting information by reading technical
documents, many colleagues and managers want to know the people working on their
projects and develop a trusting relationship with them. They use informal discussions about
the project to develop these relationships.
Therefore, project managers must he good at nurturing relation-ships through good
communication. Many experts believe that the difference between good project managers
and excellent project managers is their ability to nurture relationships and use empathic
listening skills, as described in Chapter 9, Project human Resource Management. Effective
distribution of information depends on project managers and project team members having
good communication skills. Communicating includes many different dimensions such as
writing, speaking. and listening, and project personnel need to use all of these dimensions in
their daily routines. In addition, different people respond positively to different levels or
types of communication.

Mission MCA

131

Mission MCA

Unit 6: The Importance of Project Procurement Management

6.1 Planning Purchases and Acquisitions

Planning purchases and acquisitions involves identifying which project needs can best be
met by using products or services outside the organization. It involves deciding whether to
procure, how to procure, what to procure, how much to procure, and when to procure. An
important output of planning purchases and acquisitions is the make-or-buy decision. A
make-or-buy decision is one in which an organization decides if it is in its best interests to
make certain products or perform certain services inside the organization, or if it is better to
buy them from an outside organization. If there is no need to buy any products or services
from outside the organization, then there is no need to perform any of the other
procurement management processes. For many projects, properly outsourcing sonic
information technology functions can be a great investment, as shown in the following
examples of What Went Right.
Inputs needed for planning purchases and acquisitions include the project scope statement,
WBS and WBS dictionary, project management plan, and information on enterprise
environmental factors and organizational process assets. For example, a large clothing
company might consider outsourcing the delivery of, maintenance of, and basic user
training and support for laptops supplied to its international sales and marketing force. If
there were suppliers who could provide this service well at a reasonable price, it would
make sense to outsource, because this could reduce fixed and recurring costs for the
clothing company and let them focus on their core business of selling clothes. It is important
to understand why a company would want to procure goods or services and what inputs are
needed to plan purchases and acquisitions.
In the opening case, Marie's company hired outside consultants to help complete an
operating system conversion project, because it needed people with special-ized skills for a
short period of time. This is a common occurrence in many information technology projects.
It can be more effective to hire skilled consultants to perform specific tasks for a short
period of time than to hire or keep employees on staff full time.
However, it is also important to define clearly the scope of the project, the products,
services, or results required, market conditions, and constraints and assumptions. In Marie's
case, the scope of the project and services required were relatively clear, but her company
may not have adequately discussed or documented the market conditions or constraints
and assumptions involved in using the outside consultants.
Were there many companies that provided consultants to do operating conversion projects
similar to theirs? Did the project team investigate the background of the company that
Mission MCA

132

Mission MCA

provided the consultants? Did they list important constraints and assumptions for using the
consultants, such as limiting the time that the consultants had to complete the conversion
project or the minimum years of experience for any consultant assigned to the project? It is
very important to answer these types of questions before going into an outsourcing
agreement.

6.2 Planning Contracting

Planning contracting involves preparing the documents needed for potential sellers to
prepare their responses and determining the evaluation criteria for the contract award. The
procurement management plan, contract statement of work, make-or-buy decisions, and
project management plan are all important inputs for this process. The project team often
uses standard forms and expert judgment as tools to help them create relevant
procurement documents and evaluation criteria.
Two common examples of procurement documents include
Request for Proposal (RFP) and a Request for Quote (RFQ). A Request for Proposal (RFP) is a
document used to solicit proposals from prospective suppliers. A proposal is a document
prepared by a seller when there are different approaches for meeting buyer needs. For
example. if an organization %yams to automate its work practices or find a solution to a
business problem, it can write and issue an REP so suppliers can respond with proposals.
Suppliers might propose various hardware, software, and networking solutions to meet the
organization's need. Selections of winning sellers are often made on a variety of criteria, not
just the lowest price. Developing an RFP is often a very time-consuming process.
Organizations must do proper planning to ensure they adequately describe what they want
to pro-cure, what sellers should include in their proposals, and how they will evaluate
proposals.
A Request for Quote (RFQ) is a document used to solicit quotes or bids from prospective
suppliers. A bid, also called a tender or quote (short for quotation), is a document prepared
by sellers providing pricing for standard items that have been clearly defined by the buyer.
Organizations often use an RFQ for solicitations that involve specific items. For example, if a
company wanted to purchase 100 personal computers with specific features, it might issue
an RFQ to potential suppliers. RFQs usually do not take nearly as long to prepare as RFPs,
nor do responses to them. Selections are often made based on the lowest price bid. Writing
a good RFP is a critical part of project procurement management. Many people have never
had to write or respond to an RIP.
To generate a good REP, expertise is invaluable. Many examples of RFPs are available within
different companies, from potential contractors, and from government agencies. There are
often legal requirement Its involved in issuing RFPs and reviewing proposals, especially for
Mission MCA

133

Mission MCA

government projects. It is important to consult with experts familiar with the contract
planning process for particular organizations. To make sure the RIP has enough information
to provide the basis for a good proposal, the buying organization should try to put itself in
the suppliers' shoes. Could you develop a good proposal based on the information in the
RIP? Could you determine detailed pricing and schedule information based on the RFP?
Developing a good RIP is difficult, as is writing a good proposal.
Figure 12-4 provides a basic outline or template for an RN'. The main sections of an RFP
usually include a statement of the purpose of the RFP, back-ground information on the
organization issuing the RIP, the basic requirements for the products and/or services being
proposed, the hardware and software environment (usually important information for
information technology related proposals), a description of the RN' process, the statement
of work and schedule information. and possible appendices. A simple RFP might be three to
five pages long, while an RFP for a larger, more complicated procurement might be
hundreds of pages long.

6.3 Requesting Seller Responses

The Request Seller Responses process is when the project manager obtains the quotations,
bids and proposals from the vendor. The vendor responses should include how the project
requirements can be reached and the costs associated. Just remember there needs to be
time for the vendors to generate proposals.
Mission MCA

134

Mission MCA

The inputs into the process are:

Organizational Process Assets Organizational process assets normally have a list of

bidders. For example if one is moving into WOW (workstations on wheels), having a
group of vendors listing who have been successful in the organization is key. Once I
was going through a pilot, and our COW vendor never delivered the hanging file
folders for the ED WOWs. After escalating the issue with the company, the guy
showed up with wire ties and metal folders from staples. Needless to say, this vendor
was not on the house wide roll out.
Procurement Management Plan The Procurement Management Plan details how
to manage the procurement. It is good to refer to this and inform the prospective
vendors of your internal process.
Procurement Documents - Procurement documents are from the Plan Contracting
process which describe how the seller's response should be presented, provide
details about the required product, service, or result. Basically these are a guideline
for bids or proposals to your organization.

When obtaining bids from vendors it is a key point to keep in mind, one has to ask for the
right information in the right way. Otherwise as a project manager, you may be tagged with
favoritism.
So how does one create a sandbox for all vendors to play in and not get into sand ball wars?
The tools and techniques recommended from PMI are:
Bidder Conferences - Bidder conferences are a meeting with all the potential sellers
to assure requirements are clear for the project and the bidding process. These are
particularly useful for complex, technical, or flexible procurement specifications
because they provide a forum for discussion with everyone. An outcome of a bidder
conference maybe to change the procurement documentation in order to reflect
what sellers are capable of delivering.
Advertising - Advertising is used to increase the potential seller list by publicly stating
the solicitation in magazines, newspapers and other publications.
Develop a Qualified Sellers List - By working from organizational supplier lists, trade
organizations (like himss), or trade magazines, the project manager can determine
whether potential sellers are qualified to deliver the product, service, or result
required.
Requesting Seller Responses will help assure willing capable sellers are approached for a
proposal.
At the end of the Request Seller Responses process, you should have the following outputs:

Mission MCA

135

Mission MCA

Qualified Sellers List - The Qualified Sellers List is a list of vendors who are being
asked to submit a proposal.
Procurement Document Package - The Procurement Document Package is
instructions for how the vendor is to respond to the proposal.
Proposals - Proposals are seller prepared response which details how the seller will
deliver the required product, service, or result. Proposals are considered a formal and
legal response to the buyers request. Sometimes these are followed by on-site
vendor presentations.

6.4 Selecting Sellers

Once buyers receive proposals or bids, they can select a supplier or decide to cancel the
procurement. Selecting suppliers or sellers, often called source selection, involves
evaluating proposals or bids from sellers, choosing the best one, negotiating the contract,
and awarding the contract. It is often a long, tedious process, especially for large
procurements. Several stakeholders in the procurement process should be involved in
selecting the best supplier for the project. Often, teams of people are responsible for
evaluating various sections of the proposals.
There might be a technical team, a management team, and a cost team to focus on each of
those major areas. Often, buyers develop a short list of the top three to live suppliers to
reduce the work involved in selecting a source. The main outputs of this process are the
selected sellers, a contract, a contract management plan, resource availability information,
requested changes to the project based on the seller selected, and updates to the
procurement management plan. Experts in source selection highly recommend that buyers
use formal proposal evaluation sheets during source selection. Figure 12-5 provides a
sample proposal evaluation sheet that the project team might use to help create a short list
of the best three to five proposals. Notice that this example is a form of a weighted scoring
model as described in Chapter 4, Project Integration Management.
The score for a criterion would be calculated by multiplying the weight of that criterion by
the rating for that proposal. Adding up the scores would provide the total weighted score
for each proposal. The proposals with the highest weighted scores should be included in the
short list of possible sellers. Experts also recommend that technical criteria should not be
given more weight than management or cost criteria. Many organizations have suffered the
consequences of paying too much attention to the technical aspects of
proposals. For example, the project might cost much more than expected or take longer to
complete because the source selection team focused only on technical aspects of proposals.
Paying too much attention to technical aspects of proposals is especially likely to occur on

Mission MCA

136

Mission MCA

information technology projects. However, it is often the supplier's management teamnot

the technical teamthat makes procurement successful.

After developing a short list of possible sellers, organizations often follow a more detailed
proposal evaluation process. For example, they might list more detailed criteria for
important categories, such as the management approach. They might assign points for the
potential project manager's educational back-ground and PAW certification, his or her
presentation (meaning the sellers had to give a formal presentation as part of the evaluation
process), top management support for the project, and the organization's project
management methodologies.
If the criteria and evaluation are done well, the seller with the most points based on all of
the criteria should be offered the contract. It is customary to have contract negotiations
during the source selection process. Sellers on the short list are often asked to prepare a
best and final offer (BAFO). People who negotiate contracts for a living often conduct these
negotiations for contracts involving large amounts of money. In addition, top managers
from both the buying and selling organizations often meet before making final decisions.
The final output from the process to select sellers is a contract that obligates the seller to
provide the specified products or services and obligates the buyer to pay for them. It is also
appropriate on some projects to prepare a contract management plan to describe details
about how the contract will be managed.

6.5 Administering the Contract

Administering procurements ensures that the sellers performance meets contractual
requirements. The contractual relationship is a legal relationship and as such is subject to
state and federal contract laws. It is very important that appropriate legal and contracting
professionals be involved in writing and administering contracts.
Mission MCA

137

Mission MCA

Ideally, the project manager, a project team member, or an active user involved in the
project should be actively involved in writing and administering the contract, so that
everyone understands the importance of good procurement management. The project team
members must be aware of potential legal problems they might cause by no understanding
a contract.
For example, most projects involves changes, and these changes must be handled properly
for items under contract. Without understanding the provisions of the contract, a project
manager may not realize he or she is authorizing the contractor to do additional work at
additional costs. Therefore, changes control is an important part of the contract
administration process.
It is critical that project managers and team members watch for constructive change orders.
Constructive change orders are oral or written acts or omissions by someone with actual or
apparent authority that can be construed to have the same effect as a written change order.
For example, if a member of the buyer's project team has met with the contractor on a
weekly basis for three months to provide guidelines for performing work, he or she can be
viewed as an apparent authority.
If he or she tells the contractor to redo part of a report that has already been delivered and
accepted by the project manager, that action can be viewed as a constructive change order
and the contractor can legally bill the buyer for the additional work. Likewise, if this
apparent authority tells the contractor to skip parts of a critical review meeting in the
interests of time, the omission of that information is not the contractor's fault. The
following suggestions help ensure adequate change control and good contract
administration:
Changes to any part of the project need to be reviewed, approved, and documented by
the same people in the same way that the original part of the plan was approved.
Evaluation of any change should include an impact analysis. How will the change affect the
scope, time, cost, and quality of the goods or services being provided? There must also be a
baseline to understand and analyze changes.
Changes must be documented in writing. Project team members should document all
important meetings and telephone calls.
When procuring complex information systems, project managers and their teams must
stay closely involved to make sure the new system will meet business needs and work in an
operational environment. Do not assume everything will go fine because you hired a
reputable supplier. The buying organization needs to provide expertise as well.
Have backup plans in case the new system does not work as planned when it is put into
operation.
Mission MCA

138

Mission MCA

Several tools and techniques can help in contract administration, such as a formal contract
change control system, buyer-conducted performance reviews, inspections and audits,
performance reporting, payment systems, claims administration, records management, and
information technology to support contract administration.

6.6 Closing the Contract

The final process in project procurement management is closing procurements, sometimes

referred to as contract closure. Contract closure involves completion and settlement of contracts and resolution of any open items. The project team should determine if all work
required in each contract was completed correctly and satisfactorily. They should also
update records to reflect final results and archive information for future use. Tools to assist
in contract closure include procurement audits, negotiated settlements, and a records
management system. Procurement audits are often done during contract closure to identify
lessons learned in the entire procurement process. Organizations should strive to improve
all of their business processes, including procurement management. Ideally, all
procurements should end in a negotiated settlement between the buyer and seller.
If negotiation is not possible, then some type of alternate disputes resolution such as
mediation or arbitration can be used, and if all else fails, litigation in courts can be used to
settle contracts. A records management system provides the ability to easily organize, find,
and archive procurement-related documents. It is often an automated system, or at least
partially automated, since there can be a large amount of information related to project
procurement. Outputs from contract closure include closed procurements and updates to
organizational process assets. The buying organization often provides the seller with formal
written notice that the contract has been completed. The contract itself should include
requirements for formal acceptance and closure.

6.7 Using Software to Assist in project Procurement Management

Over the years, organizations have used various types of productivity software to assist in
project procurement management. For example, most organizations use word-processing
software to write proposals or contracts, spreadsheet software to create proposal
evaluation worksheets, databases to track suppliers, and presentation software to present
procurement-related information. Many companies are now using more advanced software
to assist in procurement management. III fact. the term "e-procurement" often describes
various procurement functions that are now done electronically. A 2008 Wikipedia entry for
e-procurement described seven types of e-procurement:

Mission MCA

139

Mission MCA

Web-based ERP (Electronic Resource Planning): Creating and approving purchasing

requisitions, placing purchase orders and receiving gorids and services by using a software
system based on Internet technology.
e-MR0 (Mohoenance, Repair and Overhaul): The same as web-based ERP except that the
goods and services ordered are non-product related MR0 supplies.
e-sourcing,: Identifying new suppliers for a specific category of purchasing requirements
using Internet technology.
e-tendering: sending requests for information and prices to suppliers and receiving the
responses of suppliers using Internet technology.
e-reverse auctioning: using internet technology to buy goods and services froma number
of known or unknown suppliers.
e-informing: gathering and distributing purchasing information both from and to internal
and external parties using internet technology.
e-market sites: Expands on web based ERP to open value chains. Buying communities can
access preferred suppliers products and services, add to shopping carts, create requisition,
seek approval, receipt purchase order and process electronic invoices with integration to
suppliers supply chains and buyers financial systems.

6.8 Out Sourcing

Outsourcing is the contracting out of an internal business process to a third-party
organization.
Outsourcing sometimes involves transferring employees and assets from one firm to
another, but not always. Outsourcing is a practice that should not be considered without
considering the impact on the organization
The definition of outsourcing includes both foreign and domestic contracting, and
sometimes includes offshoring, which means relocating a business function to another
country.[5] Financial savings from lower international labor rates is a big motivation for
outsourcing/offshoring.
The opposite of outsourcing is called insourcing, which entails bringing processes handled by
third-party firms in-house, and is sometimes accomplished via vertical integration. However,
a business can provide a contract service to another business without necessarily insourcing
that business process

Mission MCA

140

Mission MCA

6.8.1 The Beginning of the outsourcing phenomenon

6.8.2 Types of outsourcing relationship
6.8.3 The realities of outsourcing
6.8.4 Managing the outsourcing relationship

Mission MCA

141

Mission MCA

Unit 7: The Risk Management Plan

7.1 Introduction
In the last chapter you learned how to develop a baseline project plan. This project plan
isbased on a number of estimates that reflect our understanding of the current situation,
theinformation available, and the assumptions we must make. The fact that we must
estimate implies a degree of uncertainty in predicting the outcome of future events.
Although no onecan predict the future with 100 percent accuracy, having a solid foundation,
in terms ofprocesses, tools, and techniques, can increase our confidence in these
estimates.Unfortunately, things seldom go according to plan because the project must
adaptto a dynamic environment. Project risk management is becoming an importantsubdiscipline of software engineering. It focuses on identifying, analyzing, anddeveloping
strategies for responding to project risk efficiently and effectively (Jones1994). It is
important, however, to keep in mind that the goal of risk management isnot to avoid risks at
all costs, but to make well-informed decisions as to what risks areworth taking and to
respond to those risks in an appropriate manner (Choo 2001).
Project risk management also provides an early warning system for impendingproblems that
need to be addressed or resolved. Although risk has a certain negativeconnotation, project
stakeholders should be vigilant in identifying opportunities.Although many associate
uncertainty with threats, it is important to keep in mind thatthere is uncertainty when
pursuing opportunities, as well.It is unfortunate that many projects do not follow a formal
risk managementapproach (Jones 1994). Because of their failure to plan for the unexpected,
manyorganizations find themselves in a state of perpetual crisis characterized by an
inabilityto make effective and timely decisions. Many people call this approach crisis
managementor fire fighting because the project stakeholders take a reactive approach
oronly address the project risks after they have become problems. Several common
mistakesto managing project risk include:

Not Understanding the Benefits of Risk ManagementOften the project sponsor or client
demands results. They may not care how the project teamachieves its goal and objectives
just as long as it does! The project managerand project team may rely on aggressive risk
taking with little understandingof the impact of their decisions (Lanza 2001). Conversely,
project risks mayalso be optimistically ignored when, in reality, these risks may become
realand significant threats to the success of the project. Unfortunately, risks areoften
schedule delays, quality issues, and budget overruns just waiting to happen (Wideman
1992). Risks can result in sub-par productivity and higher thanaverage project failure rates
(Kulik 2000).
Not Providing Adequate Time for Risk ManagementRisk management andthe ensuing
processes should not be viewed as an add-on to the project planning process, but should be
integrated throughout the project life cycle(Lanza 2001). The best time to assess and plan
for project risk, in fact, is atthe earliest stages of the project when uncertainty for a project
is the highest.Catastrophic problems or surprises may arise that require more resources
tocorrect than would have been spent earlier avoiding them (Choo 2001). It isbetter to
Mission MCA

142

Mission MCA

reduce the likelihood of a risk or be capable of responding to a particularrisk as soon as

possible in order to limit the risk's impact on the project'sschedule and budget.
Not Identifying and Assessing Risk Using a Standardized ApproachNot having a
standardized approach to risk management can overlook both threats andopportunities
(Lanza 2001). Consequently, more time and resources will beexpended on problems that
could have been avoided; opportunities will bemissed; decisions will be made without
complete understanding or information; the overall likelihood of success is reduced; and
catastrophic problems orsurprises may occur without advanced warning (Choo 2001).
Moreover, theproject team may find itself in a perpetual crisis mode. Over time, crisis
situations can have a detrimental effect on team morale and productivity.Capers Jones
(1994) suggests that effective and successful project risk managementrequires:
Commitment by all stakeholdersTo be successful, project risk management requires a
commitment by all project stakeholders. In particular, theproject sponsor or client, senior
management, the project manager, and theproject team must all be committed. For many
organizations, a new environment and commitment to following organizational and project
processesmay be required. For many managers, the first impulse may be to shortcutor
sidestep many of these processes at the first sign that the project is introuble. A firm
commitment to a risk management approach will not allowthese impulses to override the
project management and risk managementprocesses that the organization has in place.
Stakeholder ResponsibilityIt is important that each risk have an owner.This owner is
someone who will be involved in the project, who will takethe responsibility to monitor the
project in order to identify any new orincreasing risks, and who will make regular reports to
the project sponsoror client. The position may also require the risk owner to ensure that
adequate resources be available for managing and responding to a particularproject risk.
Ultimately, however, the project manager is responsible forensuring that appropriate risk
processes and plans are in place.
Different Risks for Different Types of ProjectsIn a study that looked at ITproject risks,
Jones (1994) found that patterns of risk are different across different types of IT projects.
The results of this study are summarized in Table 8.1.The implication is that each project has
its own unique risk considerations. Toattempt to manage all projects and risks the same way
may spell disaster.The remainder of this chapter will incorporate many of the processes and
conceptsoutlined in the Project Management Body of Knowledge (PMBOK) that definethe
processes of risk management. More specifically, these processes include:
Risk Management PlanningDetermining how to approach and plan theproject risk
management activities. An output of this process is the development of a risk management
plan.
Risk IdentificationDeciding which risks can potentially impact the project. Risk
identification generally includes many of the project stakeholdersand requires an
understanding of the project's goal, as well as the project'sscope, schedule, budget, and
quality objectives.

Mission MCA

143

Mission MCA

Qualitative Risk AnalysisFocusing on a qualitative analysis concerning theimpact and

likelihood of the risks that were identified.
Quantitative Risk AnalysisUsing a quantitative approach for developing aprobabilistic
model for understanding and responding to the risks identified.
Risk Response PlanningDeveloping procedures and techniques to reducethe threats of
risks, while enhancing the likelihood of opportunities.
Risk Monitoring and ControlProviding an early warning system to monitoridentified risks
and any new risks. This system ensures that risk responses havebeen implemented as
planned and had the effect as intended.

7.2 IT Project Risk Management, Planning Process

To manage risk, we first need to have a definition of risk. Although Webster s
dictionarydefines risk as "hazard; peril; or exposure to loss or injury, "the PMBOK defines
project risk as:An uncertain event or condition that, if it occurs, has a positive ornegative
effect on the project objectives. (127)The PMBOK definition provides an important starting
point for understandingrisk. First, project risk arises from uncertainty. This uncertainty
comes from ourattempt to predict the future based on estimates, assumptions, and limited
information.Although project risk has a downside resulting from unexpected problems or
threats,project risk management must also focus on positive events or
opportunities.Therefore, it is important that we understand what those events are and how
they mayimpact the project beyond its objectives. It is also important that we understand
Mission MCA

144

Mission MCA

notaspects of the project throughout the life of a project. The PMBOK defines projectrisk
management as:
The systematic process of identifying, analyzing, and responding toproject risk. It includes
maximizing the probability and consequencesof positive events and minimizing the
probability and consequencesof adverse events. (127)
This PMBOK definition of risk management suggests that a systematic processis needed to
effectively manage the risk of a project. In this section, an approach forrisk management
planning is introduced. It is illustrated in Figure 8.1.The framework presented in Figure 8.1
outlines seven steps for managing IT projectrisk. Each of these steps will be discussed in
more detail throughout the chapter.Risk planning is the first step and begins with having a
firm commitment to theentire risk management approach from all project stakeholders.
This commitmentensures that adequate resources will be in place to properly plan for and
managethe various risks of the IT project. These resources may include time, people,
andtechnology. Stakeholders also must be committed to the process of identifying,
analyzing, and responding to threats and opportunities. Too often plans are disregarded at
the first sign of trouble, and instinctive reactions to situations can lead to perpetual crisis
management. In addition to commitment, risk planning also focuses on preparation. It is
important that resources, processes, and tools be in place to adequately plan the activities
for project risk management. Systematic preparation and planning can help minimize
adverse effects on the project while taking advantage of opportunities as they arise. Once
commitment has been obtained and preparations have been made, the next step entails
identifying the various risks to the project. Both threats and opportunities must be
identified. When identifying threats to a project, they must be identified clearly so that the
true problem, not just a symptom, is addressed. Moreover, the causes and effects of each
risk must be understood so that effective strategies and responses can

Mission MCA

145

Mission MCA

Figure 8.1 IT Project Risk Management Processes

be made. A framework for understanding the sources and nature of IT project riskswill be
introduced in the next section; however, it is important to keep in mind thatproject risks are
rarely isolated. Risks tend to be interrelated and affect the project and itsstakeholders
differently.
Risk Assessment
Once the project risks have been identified and their causes and effects understood, the
next step requires that we analyze these risks. Answers to two basic questions are required:
What is the likelihood of a particular risk occurring? And, what is the impact on the project if
it does occur? Risk assessment provides a basis for understanding how to deal with project
risks. To answer the two questions, qualitative and quantitative approaches can be used.
Several tools and techniques for each approach will be introduced later. Assessing these
risks helps the project manager and other stakeholders prioritize and formulate responses
to those risks that provide the greatest threat or opportunity to the project. Because there
is a cost associated with responding to a particular risk, risk management must function
within the constraints of the project's available resources.
Mission MCA

146

Mission MCA

Risk Strategies
The next step of the risk planning process is to determine how to deal with the
variousproject risks. In addition to resource constraints, an appropriate strategy will
bedetermined by the project stakeholders' perceptions of risk and their willingness totake
on a particular risk. Essentially, a project risk strategy will focus on one of thefollowing
approaches:
Accept or ignore the risk.
Avoid the risk completely.
Reduce the likelihood or impact of the risk (or both) if the risk occurs.
Transfer the risk to someone else (i.e., insurance).
In addition, triggers or flags in the form of metrics should be identified to drawattention to a
particular risk when it occurs. This system requires that each risk havean owner to monitor
the risk and to ensure that resources are made available in order torespond to the risk
appropriately. Once the risks, the risk triggers, and strategies orresponses are documented,
this document then becomes the risk response plan.
Risk Monitoring and Control
Once the salient project risks have been identified and appropriate responses
formulated,the next step entails scanning the project environment so that both identified
andunidentified threats and opportunities can be followed, much like a radar screen follow
ships. Risk owners should monitor the various risk triggers so that well-informed
decisionsand appropriate actions can take place.
Risk Response
Risk monitoring and control provide a mechanism for scanning the project environmentfor
risks, but the risk owner must commit resources and take action once a risk threat
oropportunity is made known. This action normally follows the planned risk strategy.
Risk Evaluation
Responses to risks and the experience gained provide keys to learning. A formal
anddocumented evaluation of a risk episode provides the basis for lessons learned andlays
the foundation for identifying best practices. This evaluation should consider theentire risk
management process from planning through evaluation. It should focus onthe following
questions:
How did we do?
What can we do better next time?
What lessons did we learn?
What best practices can be incorporated in the risk management process?

Mission MCA

147

Mission MCA

The risk planning process is cyclical because the evaluation of the risk responsesand the risk
planning process can influence how an organization will plan, prepare,and commit to IT risk
management.

7.3 Identify IT Project Risk

Risk identification deals with identifying and creating a list of threats and opportunitiesthat
may impact the project's goal and/or objectives. Each risk and its characteristicsare
documented to provide a basis for the overall risk management plan.
An IT Project Risk Management Framework
Identifying and understanding the risks that will impact a project is not always a
straightforward task. Many risks can affect a project in different ways and during different
phases of the project life cycle. Therefore, the process and techniques used to identify risks
must include a broad view of the project and attempt to understand a particular risk's cause
and impact among the various project components. Figure 8.2 provides a framework for
identifying and understanding the sources and impacts of IT project risks.
At the core of the IT project risk framework is the MOV, or measurable organizational value.
The MOV is the goal of the project that defines the measurable value the organization
expects from the project. It is both a measure and definition of project success. The next
layer of the framework includes the project objectives in terms of scope, quality, schedule,
and budget. Although these objectives are not by themselves sufficient conditions for
success, together they do play a critical role in supporting the MOV. The third layer focuses
on the sources of IT project risk. Risks can arise as a result of the various people or
stakeholders
associated
with
a
project,
legal
considerations,

Mission MCA

148

Mission MCA

Figure 8.2 IT Project Risk Framework

the processes (project and product), the environment, the technology, the organization, the
product, and a catchall category called other. The next layer focuses on whether the sources
of risk are internal or external to the project. It is important to make this distinction because
a project manager is responsible and accountable for all project risks internal to the project.
For example, if a project team member is not adequately trained to use a particular
technology, then the project's objectivesscope, schedule, budget, and qualitymay be
impacted. In turn, this lack of training may inhibit the project from achieving its goal or
MOV. Once this project risk has been identified along with its impact, the project manager
can avoid or mitigate the risk by sending this particular project team member to training or
by assigning certain critical tasks to a more experienced or skillful team member.
On the other hand, a project manager may not be responsible for external risks. For
example, a project manager would not be responsible or accountable if the project was
cancelled because the organization sponsoring the project went bankrupt. The distinction
between internal and external risks is not always clear. For example, even though a
particular hardware or software vendor may be external to the project, the project manager
may still be responsible if that vendor is unable to deliver required technology resources. If
the project manager chose that particular vendor, he or she would then be responsible or
Mission MCA

149

Mission MCA

accountable for that risk. In short, a project manager will (or should) have control over
internal risks, but not external risks. That distinction does not mean the project manager can
ignore external risks. These risks can have a significant impact on the project, as well as the
project manager's employment! The fifth layer of the IT project risk management
framework includes three different types of risks:
known risks, known-unknown risks, and unknown-unknownrisks.

Applying the IT Project Risk Management Framework

Wideman (1992) defines known risks as events that are going to occur. In short, these
events are like death and taxesthey will happen and there is no uncertainty about it. On
the other hand, known-unknowns are identifiable uncertainty. For example, if you own a
home or rent an apartment, you know that you will receive a bill next month for the utilities
you use. The precise amount you will owe the utility company will be unknown until you
receive the actual bill. Unknown-unknown risks are residual risks or events that we cannot
even imagine happening.
For example, it was not too long ago that people had never even heard about the Internet.
How could they comprehend the impact it would have on many of us? Unknown-unknown
risks are really just a way to remind us that there may be a few risks remaining even after
we may think we identified them all. In general, these are the risks that we identify after
they have occurred. The outer layer provides a time element in terms of the project life
cycle. It may help us determine or identify when risks may occur, but also remind us that
they may change over the life of the project. Although risk management is an important
concern at the beginning of a project, the IT project risk management framework reminds us
that we must be vigilant for opportunities and problems throughout the project life cycle.
The GTS vignette at the beginning of the chapter can be analyzed using the process
representedin Figure 8.1. For example, the risk faced by the GTS team could be defined as:
A threat that occurred in the develop project charter and project plan phase.
It was an unknown-unknown risk because it was identified after it occurredand, therefore,
caught the GTS project team off guard.
It was an external risk, and the project manager and project team should notbe held
responsible for the economic downturn experienced by Husky Air.
The sources of risk to the GTS project include environment (economic),organizational (the
client Husky Air) and people (if you would like to arguethat Husky Air's management was lax
in anticipating this problematic event).
The impact on the GTS project was significant because it would affect theproject's scope,
schedule, and budget. Since Tim Williams was able to renegotiate the contract based on a
trimmed scope, we can assume that qualitywould not be an issue. But if Husky Air's
management insisted on maintaining the original scope, schedule, and budget, chances are
good thatquality would become an issue, especially if, for example, the scheduledtesting
time had to be shortened in order to meet the scheduled deadline.
Mission MCA

150

Mission MCA

It is likely that the project's MOV would change as well because the project team would
not complete the scope as originally planned. This, in turn, would determine the revised
scope, schedule, and budget for the project. This example shows how a risk can be
understood after it occurs. The framework can also be used to proactively identify IT project
risks. For example, a project team could begin with the project phases defined in the outer
core of the framework. Using the project's work breakdown structure (WBS) and the
individual work packages, the team could identify the risks for each of the work packages
under the various project phases. Again, it is important that both threats and opportunities
be identified. These risks could be classified as either known risks or known-unknown risks.
The category of unknown-unknown risks should serve as a reminder to keep asking the
question, What other threats or opportunities have we not thought about? Hopefully, the
project team will do a more thorough job of identifying risks early in the project and reduce
the likelihood of being surprised later. The risks identified by the team can then be
categorized as external or internal to the project. The internal risks are the direct
responsibility of the project manager or team, while external risks may be outside their
control. Regardless, both external and internal risks must be monitored and responses
should be formulated. The next step involves identifying the various sources of risk. Instead
of trying to neatly categorize a particular risk, it may be more important to understand how
the sources of risk are interrelated with each other. In addition, it may be a situation where
precise definitions get in the way of progress. Instead of arguing or worrying about the exact
source of a particular risk, it is more important the stakeholders understand the complex
nature of a risk.
Each risk-source category may mean different things to different stakeholders. Depending
on the project, the stakeholders should be free to develop their own definitions and
interpretations for each risk source category. They should also feel free to add categories, as
needed. After identifying the nature and characteristics of a particular risk, the project team
can assess how a particular risk will impact the project. At this point, the team should focus
on the project objectives that would be impacted if a particular risk occurred and, in turn,
whether the project's MOV or goal would be impacted. Later on, these risks can be assessed
to determine how the objectives will be impacted. The above example shows how, working
from the outside and then inward toward the center of the model, risks can be identified
using the IT project risk framework.
This procedure works well as a first pass and when using the project plan or WBS as a source
of input. Many threats and opportunities may, however, be overlooked when relying only
on the WBS. The project team could start with the inner core of the IT risk framework and
work outward. For example, the project team could identify how the MOV may be
IDENTIFYING IT PROJECT RISKS 177 affected in terms of threats or opportunities that affect
the project's scope, schedule, budget, or quality. Working away from the center, the team
could identify possible sources of risk and then categorize whether the risk is internal or
external, known, known-unknown, or unknown-unknown (i.e., did we miss something?),
and when during the project life cycle this particular risk might occur.

Mission MCA

151

Mission MCA

Tools and Techniques

Identifying risks is not always easy. Risks tend to be interrelated and identifying each and
every risk may not be possible or economically feasible. People may not want to admit that
potential problems are possible for fear of appearing incompetent. As a result, stakeholders
may deny or downplay a particular risk. Still, people and organizations have different
tolerances for risk, and what may be considered a normal risk for one stakeholder or
organization may be a real concern for another. So, the stakeholders may concentrate on a
particular risk (that may or may not occur) at the expense of other risks that could have the
same impact on the project. It is, therefore, important that the project manager and team
guide the risk management process. Risk identification should include the project team and
other stakeholders who are familiar with the project's goal and objectives. Using one or
more of the following tools, the IT project risk framework introduced earlier in this section
can provide direction for identifying the threats and opportunities associated with the
project:
Learning CyclesThe concept of learning cycles was introduced inChapter 4. The project
team and stakeholders can use this technique,whereby they identify facts (what they know),
assumptions (what theythink they know), and research (things to find out), to identify
various risks.Using these three categories, the group can create an action plan to
testassumptions and conduct research about various risks. Based on the team'sfindings,
both risks and lessons learned can then be documented.
BrainstormingBrainstorming is a less structured activity than learningcycles. Here the
team could use the IT risk framework and the WBS to identify risks (i.e., threats and
opportunities) starting with the phases of the projectlife cycle and working towards the
framework's core or MOV or workingfrom the MOV outward toward the project phases. The
key to brainstormingis encouraging contributions from everyone in the group. Thus, initially
ideasmust be generated without being evaluated. Once ideas are generated by thegroup as
a whole, they can be discussed and evaluated by the group.
Nominal Group Technique (NGT)The NOT is a structured technique foridentifying risks
that attempts to balance and increase participation(Delbecq and Van de Van 1971). Using
the NGT:
a. Each individual silently writes her or his ideas on a piece of paper.
b. Each idea is then written on a board or flip chart one at a time in around-robin fashion
until each individual has listed all of his or her ideas.
c. The group then discusses and clarifies each of the ideas.
d. Each individual then silently ranks and prioritizes the ideas.
e. The group then discusses the rankings and priorities of the ideas.
f. Each individual ranks and prioritizes the ideas again.
g. The rankings and prioritizations are then summarized for the group.
Delphi TechniqueIf the time and resources are available, a group ofexperts can be
assembledwithout ever having to meet face-to-face. Usingthe Delphi technique, a group
of experts are asked to identify potential risksor discuss the impact of a particular risk.
Mission MCA

152

Mission MCA

Initially, in order to reduce thepotential for bias, the experts are not known to each other.
Their responsesare collected and made available anonymously to each other. The experts
arethen asked to provide another response based upon the previous round ofresponses.
The process continues until a consensus exists. The advantage ofusing the Delphi technique
is the potential for getting an insightful view into athreat or opportunity; but the process
takes time and may consume a goodportion of the project's resources.
InterviewingAnother useful technique for identifying and understandingthe nature of IT
project risks is to interview various project stakeholders.This technique can prove useful for
determining alternative points of view;but the quality of the information derived depends
heavily on the skills of theinterviewer and the interviewees, as well as the interview process
itself.
ChecklistsChecklists provide a structured tool for identifying risks thathave occurred in the
past. They allow the current project team to learn frompast mistakes or to identify risks that
are known to a particular organization orindustry. One problem with checklists is that they
can lead to a false sense ofsecurityi.e., if we check off each of the risks on the list, then we
will havecovered everything. Table 8.2 provides an example of items that may beincluded in
a project risk checklist.
*SWOT AnalysisSWOT stands for Strengths,Weaknesses, Opportunities, and Threats.
Brainstorming, NOT, or the Delphi technique couldbe used to identify and understand the
nature of ITproject risks by categorizing risks using the framework illustrated in Figure 8.3.
The usefulness ofusing SWOT analysis is that it allows the projectteam to identify threats
and opportunities as well astheir nature in terms of project or organizationalstrengths and
weaknesses.
.*Cause-and-Effect DiagramsThe most widelyknown and used cause-and-effect diagram is
thefishbone, or Ishikawa, diagram developed by KaoruIshikawa to analyze the causes of
poor quality inmanufacturing systems. The diagram can also beused for understanding the
causes or factors of aparticular risk, as well as its effects. An example ofan Ishikawa diagram
is illustrated in Figure 8.4.The diagram shows the possible causes and effectsof a key
member of the team leaving the project.This technique itself can be used individually or
ingroups by using the following steps:
a. Identify the risk in terms of a threat or opportunity.

Mission MCA

153

Mission MCA

b. Identify the main factors that can cause therisk to occur.

c. Identify detailed factors for each of themain factors.
d. Continue refining the diagram until satisfied that the diagram is complete.
Past ProjectsOne of the themes in this texthas been the integration of knowledge
managementto support the project managementprocesses. Lessons learned from past
projectscan provide insight and best practices for identifyingand understanding the nature
of IT projectrisks. The usefulness of these lessons takestime and a commitment by the
organization andproject team to develop a base of knowledgefrom past projects. The value
of this knowledgebase will increase as the base does, allowingproject teams to learn from
the mistakes and
a. successes of others.

Mission MCA

154

Mission MCA

7.4 Risk Analysis and Assessment

The framework introduced in the previous section provides tools for identifying
andunderstanding the nature of risks to IT projects. The next step requires that those
risksbe analyzed to determine what threats or opportunities require attention or a
response.Risk analysis and assessment provides a systematic approach for evaluating the
risksthat the project stakeholders identify. The purpose of risk analysis is to determineeach
identified risk's probability and impact on the project. Risk assessment, on theother hand,
focuses on prioritizing risks so that an effective risk strategy can be formulated.In short,
which risks require a response? To a great degree, this will be determinedby the project
stakeholders' tolerances to risk.
There are two basic approaches to analyzing and assessing project risk. The firstapproach is
more qualitative in nature because it includes subjective assessments basedon experience
or intuition. Quantitative analysis, on the other hand, is based on mathematicaland
statistical techniques. Each approach has its own strengths and weaknesseswhen dealing
with uncertainty, so a combination of qualitative and quantitativemethods provides
valuable insight when conducting risk analysis and assessment.
Qualitative Approaches

Mission MCA

155

Mission MCA

Qualitative risk analysis focuses on a subjective analysis of risks based upon a

projectstakeholder's experience or judgment. Although the techniques for analyzing
projectrisk qualitatively can be conducted by individual stakeholders, it may be more
effectiveif done by a group. This group process allows each stakeholder to hear other points
ofview and supports open communication among the various stakeholders. As a result,
abroader view of the threats, opportunities, issues, and points of view can be discussedand
understood.

Figure 8.4 Cause and Effect Diagram

Expected Value The concept of expected value provides the basis for both qualitative and
quantitative risk analysis. Expected value is really an average, or mean, thattakes into
account both the probability and impact of various events or outcomes. Forexample, let's
assume that a project manager of a consulting firm would like to determinethe expected
return or payoff associated with several possible outcomes orevents. These outcomes or
events, in terms of possible schedule scenarios, determinethe return or profit the project
will return to the consulting firm. The project mangerbelieves each outcome has a
probability of occurring and an associated payoff. Theproject manager's subjective beliefs
are summarized in a payoff table in Table 8.3.As you can see from Table 8.3, the project
manager believes that the project hasa small chance of finishing twenty days early or twenty
days late.
The payoff for finishingthe project early is quite high, but there appears to be a penalty for
completingthe project late. As a result, the expected value or return to the consulting firm
is$88,000. Since each event is mutually exclusive (i.e., only one of the five events canoccur),
the probabilities must sum to 100 percent.Decision Trees Similar to a payoff table, a
decision tree provides a visual, orgraphical, view of various decisions and outcomes. Let's
Mission MCA

156

Mission MCA

assume that a project isgoing to overrun its schedule and budget. The project manager is
contemplatingreducing the time allocated to testing the application system as a way of
bringing theproject back within its original schedule and budget objectives.The project
manager, then, is faced with a decision about whether the projectteam should conduct a full
systems test as planned or shorten the time originally allocatedto testing. The cost of a full
test will be $10,000; but the project managerbelieves that there is a 95 percent chance the
project will meet the quality standards setforth by the client. In this case, no additional
rework will be required and no additionalcosts will be incurred.
Since there is only a 5 percent chance the system will not meetthe standards, the project
manager believes that it would only require a small amount ofrework to meet the quality
standards. In this case, it will cost about $2,000 in resourcesto bring the system within
standards.On the other hand, the shortened test will cost less than the full test and bring
theproject back on track. But, if the project team limits the testing of the system, it willvery
likely lower the probability of the system meeting the quality standards.Moreover, a failure
will require more rework and cost more to fix than if these problemswere addressed during
a full testing of the system. As you can see from Figure8.5, a limited testing of the system
will cost only $8,000, but the chances of the systemfailing to meet the quality standards
increase.
Moreover, the time and cost to completethe rework will be higher.Even though the project
manager still has a difficult decision to make, it nowbecomes a more informed decision. If
the project team continues with the testing activitiesas planned, there is a very good chance
that the system will not require a great deal ofrework. On the other hand, reducing the time
to test the system is more of a gamble.Although there is a 30 percent chance the limited
testing will save both time and money,there is a high probability that the system will not
pass or meet the quality standards. As aresult, the required rework will make the project
even later and more over its budget. Ifyou were the project manager, what decision would
you make?
Risk Impact Table We can create a risk impact table to analyze and prioritize variousIT
project risks. Let's use another example. Suppose a project manager has identifiedseven
risks that could impact a particular project.The left-hand column of Table 8.4 lists the
possible risks that were identifiedusing the IT project risk framework introduced in the last
section. For simplicity, wewill focus only on risks in terms of threats, but opportunities could
be analyzed andassessed using the same technique.The second column lists the subjective
probabilities for each of the risks.
In thiscase, the probabilities do not sum to 100 percent because the risks are not
mutuallyexclusive. In other words, none, some, or all of the risk events could occur. A
probabilityof zero indicates that a probability has absolutely no chance of occurring, whilea
probability of 100 percent indicates an absolute certainty that the event will occur.The next
column provides the potential impact associated with the risk event occurring.This also is a
subjective estimate based on a score from 0 to 10, with zero beingno impact and ten having
a very high or significant impact on the project.

Mission MCA

157

Mission MCA

Figure 8.5 Decision Tree Analysis

Mission MCA

158

Mission MCA

Once a probability and an impact are assigned to each risk event, they are
multipliedtogether to come up with a risk score. Although this score is based on the
subjectiveopinions of the project stakeholders, it does provide mechanism for
determiningwhich risks should be monitored and which risks may require a response. Once
a riskscore is computed for each risk, the risks can be prioritized as in Table 8.5.Table 8.5
shows that "Response time not acceptable to users/client" and"Technology does not
integrate with existing application" are the two most significantrisks to this project. The risk
scores for all of the risks include the stakeholders risktolerances and preferences since the
subjective probabilities and impacts will reflectthese tolerances and preferences.The risk
scores can be further analyzed using a risk classification scheme introducedby Robert Tusler
(Tusler 1998). Figure 8.6 shows how the risk analysis can beused to classify the different
risks.As you can see in Figure 8.6, each risk from Table 8.4 is plotted against its
probabilityand potential impact. Tusler suggests that risks can be classified according tothe
four quadrants:
KittensRisks that have a low probability of occurring and a low impacton the project.
These risks are rarely a source of trouble and, therefore, agreat deal of time and resources
should not be devoted to responding tothese threats. Similarly, these types of opportunities
are not worth pursuingsince they offer little payback and have little chance of fruition.
PuppiesPuppies are similar to kittens, but can become a source of problems very quickly
because they have a high probability of occurring. Likethe risks that they represent, puppies
can grow into large troublesome dogsunless they are trained properly. Similarly, these types
of risks must bewatched so that corrective action can be taken before they get out of hand.
TigersThese types of risks have a high probability of occurring and ahigh impact. Similar
to the dangerous animals they represent, they must beneutralized as soon as possible.
AlligatorsAlligators are not a problem if you know where they are, otherwise, they can
be. These risks have a low probability of occurring, but ahigh impact if they do. These types
of risks can beavoided with care.Quantitative approaches to project risk analysis
includemathematical or statistical techniques that allow us tomodel a particular risk
situation. At the heart of many ofthese models is the probability distribution.
Probabilitydistributions can be continuous or discrete.Discrete Probability Distributions
Discreteprobability distributions use only integer or wholenumbers where fractional values
are not allowed or do notmake sense. For example, flipping a coin would allow foronly two
outcomesheads or tails. If you wantedto find the

Mission MCA

159

Mission MCA

Mission MCA

160

Mission MCA

Mission MCA

161

Mission MCA

Mission MCA

162

Mission MCA

Mission MCA

163

Mission MCA

Mission MCA

164

Mission MCA

Figure 8.10 provides an example of a triangular distribution where a = 4, m = 6, andb= 10.

Simulations In general, when people want to study a particular phenomenon, theypick a
random sample. For example, if you wanted to know more about customer satisfactionor
consumer tastes, you could survey a certain number of randomly selectedcustomers and
then analyze their responses. On the other hand, if you wanted to studyprojects, you might
randomly select a certain number of projects and then collect dataabout certain attributes
in order to make comparisons. This same approach can beused to analyze and understand
how different input variables (e.g., task durations) canimpact some output variable (e.g.,
project completion date).
Monte Carlo simulation is a technique that randomly generates specific values for avariable
with a specific probability distribution. The simulation goes through a specificnumber of
iterations or trials and records the outcome. For example, instead of flipping acoin five
hundred times and then recording the outcome to see whether we get about thesame
number of heads as we do tails, a Monte Carlo simulation can literally flip the coinfive
hundred times and record the outcome for us. We can perform a similar simulationusing
almost any continuous or discrete probability distribution.If we would like to apply our
Mission MCA

165

Mission MCA

knowledge of probability distributions to risk analysis,there are a number of software tools

available to model our project and developsimulations. One tool is an add-on to Microsoft
Project called @Risk, by PalisadeCorporation. Let's say that a project manager has a
project with five tasks (A throughE) and has created a project plan using Microsoft Project.
As you can see from Figure8.11, the project is estimated to be completed in sixteen days.
However, each task has alevel of uncertainty in terms of each task's estimated duration.
Therefore, we cancreate a Monte Carlo simulation that will tell us how likely it is that the
project will

Figure 8.10 Example of a Triangular Distribution

be completed as planned. For example, Tasks A and D follow a PERT distribution,while Tasks
B and C follow a triangular distribution. In addition, Task E follows anormal distribution. The
distributions and values are listed in the @Risk Functionscolumn created by the @Risk
add-on.The Monte Carlo simulation using @Risk was set to run five hundred iterations
ortrials. The output of this simulation is illustrated in Figure 8.12. Each bar in the
histogramshows the frequency, or number of times, an iteration generated a particular
completiondate for the project based on the probability distributions for the five
tasks.Running the simulation using @Risk, the project manager can assess the likelihoodof
Mission MCA

166

Mission MCA

the project finishing on September 26 (i.e., within the original sixteen-dayestimate) by

viewing a cumulative probability distribution (see Figure 8.13).As you can see in Figure 8.13,
the probability of completing the project onSeptember 26the end of the project
manager's original sixteen-day estimateis
less than .200 or 20 percent.In addition, the project manager can conduct a sensitivity
analysis to determinethe tasks that entail the greatest risk. Figure 8.14 illustrates a tornado
graph, whichsummarizes the tasks with the most significant risks at the top. As the risks are
ranked

Figure 8.11 Risk Simulation Using @Risk for Microsoft Project

Mission MCA

167

Mission MCA

from highest to lowest, the bars of the graph sometimes resemble a tornado. The
tornadograph allows us to compare the magnitudes of impact for each of the tasks
bycomparing the size of each bar. As you can see in Figure
Figure 8.14, Task E has the
greatestpotential for impacting the project's schedule.

Mission MCA

168

Mission MCA

7.5 Risk Strategies

The purpose of risk analysis and assessment is to determine what opportunities andthreats
should be addressed. It is not feasible or advisable to respond to each andevery threat or
opportunity identified because avoiding all threats or chasing afterevery opportunity
requires resources to be diverted away from the real project work.Therefore, the risk
strategy or response to a particular risk depends on:
The nature of the risk itself Isthis really a threat to or opportunity for theproject? How
will the project be affected? At what points during the projectlife cycle will the project be
affected? What are the triggers that woulddetermine if a particular risk is occurring? Why
should the risk be taken?
The impact of the risk on the project's MOV and objectives A risk has aprobability and an
impact on the project if it occurs. What is the likelihoodof this occurring? And if this risk
occurs, how will the project be affected?What can be gained? What could be lost? What are
the chances of successor failure?
The project s constraints in terms of scope, schedule, budget, and qualityrequirements
Can a response to a particular threat or opportunity be madewithin the available resources
and constraints of the project? Will additional

resources be made available if a particular risk occurs? Can certain contractualobligations be

waived or modified? What will happen if the desired result isnot achieved?
Mission MCA

169

Mission MCA

Risk tolerances or preferences of the various project stakeholdersIs a riskfor one

stakeholder a risk for another? How much risk is each stakeholderwilling to tolerate? How
committed is each stakeholder to the risk management process? Is the potential reward
worth the effort?A response to a particular risk may follow one of the following strategies:
Accept or IgnoreChoosing to accept or ignore a particular risk is a morepassive approach
to risk response. The project stakeholders can either behopeful that the risk will not occur
or just not worry about it unless it does.This can make sense for risks that have a low
probability of occurring or alow impact. However, reserves and contingency plans can be
activeapproaches for risks that may have a low probability of occurring but witha high
impact.
Management ReservesThese are reserves that are controlled andreleased by senior
management at its discretion. These reserves are notusually included in the project's
budget, but provide a cushion for dealingwith the unexpected.
* Contingency ReservesA contingency reserve is usually controlled andreleased within
specific guidelines by the project manager when a particularrisk occurs. This reserve is
usually included in the project's budget.
Contingency plansSometimes called an alternative plan, or Plan B,this plan can be
initiated in the event a particular risk occurs. Althoughthese types of plans are viewed as
plans of last resort, they can be usefulin a variety of ways. For example, a project team
should have a disasterrecovery plan in place should a natural disaster, such as a hurricane
orearthquake, occur. This plan may have procedures and processes inplace that would allow
the project team to continue to work should its
present workplace become unusable or unavailable. This type of disasterrecovery plan is
only useful if it is up-to-date and communicated to thevarious project stakeholders.
AvoidanceThe avoidance strategy focuses on taking steps to avoid therisk altogether. In
this case, an active approach is made to eliminate or prevent the possibility of the threat
occurring.
MitigateThe term mitigate means to lessen. Therefore, a mitigation riskstrategy focuses
on lessening the probability and/or the impact of threat if itdoes occur.
TransferA transfer strategy focuses on transferring ownership of the riskto someone
else. This transfer could be in the form of purchasing insuranceagainst a particular risk or
subcontracting a portion of the project work tosomeone who may have more knowledge or
expertise in the particular area.As a result, this strategy may result in a premium, or added
cost, to managing and responding to the risk.Once the project risks and strategies are
identified, they can be documented aspart of the risk response plan. This plan should
include the following:
The project risk
The trigger which flags that the risk has occurred
Mission MCA

170

Mission MCA

The owner of the risk (i.e., the person or group responsible for monitoringthe risk and
ensuring that the appropriate risk response is carried out)
The
he risk response based on one of the four basic risk strategiesThe risk response plan can
be developed using a template, such as the one illustratedin Figure 8.15.

7.6 Risk Monitoring and Control

Once the risk response plan is created, the various risk triggers must be
continuallymonitored to keep track of the various IT project risks. In addition, new threats
andopportunities may present themselves over the course of the project, so it is
importantthat the project stakeholders be vigilant.Risk monitoring
monitoring and control should be
part of the overall monitoring and control ofthe project. Monitoring and control focus on
metrics to help identify when a risk occurs,and also on communication. The next chapter
addresses how important it is to have agood monitoring
monitoring and control system that supports
communication among the variousstakeholders and provides information essential to
making timely and effective decisions.Risk monitoring and control are analogous to a
radarscope, as Figure 8.16 shows.Threats and opportunities
opportunities present themselves at different
times. Some are on the horizon,while others are closer to affecting the project's MOV and
objectives.Various tools exist for monitoring and controlling project risk. These include:
Risk AuditsA
A knowledgeable manager or group can be useful for auditingthe project
team from time to time. The audit should focus on ensuring thatthe project manager and
team have done a good job of identifying and analyzing project risks and on ensuring that
proper procedures and processesare
processesare in place. Risk audits should be conducted by people
outside the projectteam. Using outsiders provides a fresh perspective; the project team may
betoo close to the project and miss significant threats or opportunities.
Risk ReviewsRisk
Risk audits should be conducted by individuals outside theproject team; but
risk reviews can be conducted internally. Throughout theproject life cycle, the project
stakeholders should hold scheduled, periodicrisk reviews. These reviews should be part of
each team meeting and
d partof the project team's learning cycles.
Risk Status Meetings and ReportsSimilar
Reports Similar to risk reviews, a monitoringand control system
should provide a formal communication system formonitoring and controlling project risks.

Mission MCA

171

Mission MCA

7.7 Risk Response and Evaluation

The risk triggers defined in the risk response plan provide risk metrics for
determiningwhether a particular threat or opportunity has occurred. A system for
monitoring andcontrolling risk provides a mechanism for monitoring these triggers and for
supportingcommunication among the various risk owners. The risk owners must be vigilant
inwatching for these triggers.When a trigger occurs, the project risk owner must take
appropriate action. Ingeneral, the action is responding to the risk as outlined in the risk
response plan.Adequate resources must be available and used to respond to the risk.The
outcome of the risk response will either be favourable or unfavourable.Therefore, a great
deal can be learned about the entire process of risk management(i.e., the preparedness of
risk planning, identifying risks, analyzing and assessingrisks, risk responses, and so forth).
Lessons learned can lead to the identification ofbest practices that can be shared
throughout the project organization. In summary, lessonslearned and best practices help us
to:
Mission MCA

172

Mission MCA

Increase our understanding of IT project risk in general.

Understand what information was available to managing risks and for making risk-related
decisions.
Understand how and why a particular decision was made.
Understand the implications not only of the risks but also the decisions thatwere made.
Learn from our experience so that others may not have to repeat our mistakes.

Mission MCA

173

Mission MCA

Unit VIII: Human Resource Management

8.1 Human Resource Planning

Human Resource Planning is the process of systematically forecasting the future demand
and supply for employees and the deployment of their skills within the strategic objectives
of the organization. Human resources planning is a process that identifies current and future
human resources needs for an organization to achieve it goals. It responds to the
importance of business strategy and planning in order to ensure the availability and supply
of people--both in number and quality. Human Resources Planning serves as a link between
human resources management and the overall strategic plan of an organization
Planning Process
The planning processes of most organizations define what will be accomplished within a
given time frame, along with the numbers and types of human resources that will be
needed to achieve the defined business goals. This is typically accomplished by defining
competencies that are required by workers to achieve business goals, matching people with
these competencies to the right tasks, and assessing the overall process for progress and
improvement.
Competencies
Competency-based management supports the integration of human resources planning
with business planning by allowing organizations to assess the current human resource
capacity based on employees' current skills and abilities. These skills and abilities are
measured against those needed to achieve the vision, mission and business goals of the
organization. If the available people lack necessary competencies, the organization plans
how it will develop them.
Planning to Develop Competencies
Targeted human resource strategies, plans, and programs to address gaps in the
organization's workforce are designed, developed and implemented to close the gaps. Plans
and programs can include:
targeted hiring/staffing
employee learning and education
career development
succession management
Mission MCA

174

Mission MCA

Evaluation and Improvement

These strategies and programs are monitored and evaluated on a regular basis to ensure
that they are moving the organization in the desired direction, including closing employee
competency gaps. Corrections are then made as needed.

8.2 Acquiring the Project Team

During late 1990s, the information technology job market became extremely competitive. It
was a sellers market with corporations competing fiercely for a shrinking pool of qualified,
experienced information technology professionals. In the early 2000s, the market declined
tremendously. so employers could he very selective in recruiting. Today.many organizations
again face a shortage of IT staff. Regardless of the current job market, acquiring qualified
information technology professionals is critical. There is a saying that the project manager
who is the smartest person on the team has done a poor job of recruiting! In addition to
recruiting team members, it is also important to assign the appropriate type and number of
people to work on projects at the appropriate times. This section addresses important
topics related to acquiring the project team: resource assignment, resource loading, and
resource levelling.
8.2.1 Resource Assignment
After developing a staffing management plan, project managers must work with other
people in their organizations to assign particular personnel to their projects or to acquire
additional human resources needed to staff the project. Project managers with strong
influencing and negotiating skills are often good at getting internal people to work on their
projects. However, the organization must ensure that people are assigned to the projects
that best fit their skills and the needs of the organization. The main outputs of this process
are project staff assignments, resource availability information, and updates to the staffing
management plan. Many project teams also find it useful to create a project team directory.
Organizations that do a good job of staff acquisition have good staffing plans. These plans
describe the number and type of people who are currently in the organization and the
number and type of people anticipated to be needed for the project based on current and
upcoming activities. An important component of staffing plans is maintaining a complete
and accurate inventory of employees' skills. If there is a mismatch between the current mix
of people's skills and needs of the organization, it is the project manager's job to work with
top management, hit thin resource managers, and other people in the organization to
address staffing and training needs.
It is also important to have good procedures in place for hiring subcontractors and recruiting
new employees. Since the Human Resource department is normally responsible for hiring
people, project managers must work with their human resource managers to address any
Mission MCA

175

Mission MCA

problems in recruiting appropriate people. It is also a priority to address retention issues,

especially for information technology professionals.
One innovative approach to hiring and retaining information technology staff is to offer
existing employees incentives for helping recruit and retain personnel. For example, several
consulting companies give their employees one dollar for every hour a new person they
helped recruit works. This provides an incentive for current employees to help attract new
people and to keep both the employees and the people they help to recruit working at their
respective company. Another approach that several companies are taking to attract and
retain information technology professionals is to provide benefits based on personal need.
For example, some people might want to work only four days a week or have the option of
working a couple of days a week from home. As it gets more difficult to find good
information technology professionals, organizations must become more innovative and
proactive in addressing this issue.
Several organizations, publications, and Web sites address the need for good staff
acquisition and retention. Enrolment in U.S. computer science and engineering programs
has dropped almost in half since 2000, and one-third of U.S. workers will be (wet- the age of
50 by 2010. CIO's researchers suggest that organizations rethink hiring practices and
incentives to hire and retain IT talent. For example.if it's important for IT employees to have
strong business and communications skills, organizations shouldn't focus primarily on
technical skills. A company could ref mire candidates to give a presentation to see how will
they communicate and understand the business. Also, organizations should focus on
flexibility when negotiating perks. According to the "2006 Compensation and Benefits
Report" by I ludson Highland Group, a third of IT workers said they value a flexible work
schedule more than other non-traditional benefits. "Employees are more willing to forgo
additional cash in order to have a more improved work-life balance," says Peg Buchenroth, I
ludson Highland Group's managing director of compensation and benefits.21 It is very
important to consider the needs of individuals and the organization when making recruiting
and retention decisions and to study the best practices of leading companies in these areas.
It is also important to address a growing trend in project team membersmany of them
work in a virtual environment.
8.2.2 Resource Loading
Chapter 6, Project Time Management, described using network diagrams to help manage a
project's schedule. One of the problems or dangers inherent iii scheduling processes is that
they often do not address the issues of resource utilization and availability. Hence, the
development of critical chain scheduling, as described in Chapter 6.) Schedules tend to focus
primarily on tine rather than on both time and resources, which includes people. An
important Measure of a project manager's success is how well he or she balances the tradeoffs among performance, time, and cost. During a period of crisis, it is occasionally possible
to add additional resourcessuch as additional staffto a project at little or no cost. Most
Mission MCA

176

Mission MCA

of the time, however, resolving performance, time, and cost trade-offs entails additional
costs to the organization. The project manager's goal must be to achieve project success
without increasing the costs or time required to complete the project. The key to
accomplishing this goal is effectively managing human resources on the project.
Once people arc assigned to projects, there are two techniques available to project managers that help them use project staff most effectively: resource loading and resource
levelling. Resource loading refers to the amount of individual resources an existing schedule
requires during specific time periods. Resource loading helps project managers develop a
general understanding of the demands a project will make on the organization's resources,
360 as well as on individual people's schedules. Project managers often use histograms, as
described in Figure 9-7, to depict period-by-period variations in resource loading. A
histogram can be very helpful in determining staffing needs or in identifying staffing
problems.
A resource histogram call also show when work is being over allocated to a certain per-son
or group. Over allocation means more resources than are available At: are assigned to perk
win work at a given fine. For example, Figure 9-8 provides a sample resource histogram
created in Microsoft Project. This histogram illustrates how much one individual, Joe
Franklin. is assigned to work on the project each week. The percentage numbers on the
vertical axis represent the percentage of Joe's available time that is allocated kw hint to
work on the project. The top horizontal axis represents time in weeks. Note that Joe Franklin
is over allocated most of the time. For example, for most of March and April and part of
May, Joe's work allocation is 300 percent of his available time. If Joe is normally available
eight hours per day, this means he would have to work 24 hours a day to meet this staffing
projection! Many people don't use the resource assignment features of project
management soft-ware properly.

8.2.3 Resource Leveling Developing the Project Team

Even if a project manager has successfully recruited enough skilled people to work on a
project, he or she must ensure that people can work together as a team to achieve project
goals. Many information technology projects have had very talented individuals working on
them. However, it takes teamwork to complete most projects successfully. The main goal of
team development is to help people work together more effectively to improve project
performance. Dr. Bruce Tuck man published his four-stage model of team development in
1965 and modified it to include an additional stage in the 1970s. The Tuckman model
describes five stages of team development:
1. Forming involves the introduction of team members, either at the initiation of the team,
or as new members arc introduced. This stage is necessary. but little work is actually
achieved.
Mission MCA

177

Mission MCA

2. Storming occurs as team members have different opinions as to how the team should
operate. People test each other, and there is often conflict within the team.
3. Norming is achieved when team members have developed a common working method,
and cooperation and collaboration replace the conflict and mistrust of the previous phase.
4. Performing occurs when the emphasis is on reaching the team goals, rather than working
on team process. Relationships are settled, and team members re likely to build loyalty
towards each other. At this stage, the team is able to manage tasks that are more complex
and cope with greater change.
5. Adjourning involves the break-up of the team after they successfully reach their goals and
complete the work
There is an extensive body of literature on team development. This section will high-light :I
few important tools and techniques for team development. including training, tea in-kidding
activities, and reward and recognition systems.
Training
Project it managers often recommend that people take specific training courses to improve
individual mid team development. For example, Sarah In mi the opening ease had gone
through training in emotional intelligence and dealing with difficult people. She was familiar
with the mirroring technique and felt comfortable using that approach with Ben. Many
other people would not have reacted so quickly and effectively in die same situation. If Ben
and Sarah did reach agreement on what actions they could take to resolve the F-44 aircraft
program's information technology problems, it might result in a new project to develop and
deliver a new system for Ben's group. If Sarah became the project manager for this new
project, she would understand the need for special training in interpersonal skills for specific
people in her and Ben's departments. Individuals could take special training classes to hit
prove their personal skills. If Sarah thought the whole project team could benefit In 'Iii
taking training together to learn to work as a team, she could arrange for a special teambuilding session for the entire project team and key stakeholders.
It is very important to provide training in a just-in-time fashion. For example, if Sarah was
preparing for a technical assignment where she would need to learn a new programming
language, training to deal with difficult people would not help her much. However, the
training was very timely for her new consulting position. Many organizations provide
clearing opportunities for their employees so they can learn specific skills at ally time and
:my place. They have also found e-learning to sometimes he more cost-effective titan
traditional instructor-led training courses. It is important to make sure that the timing and
delivery method for the training is appropriate for specific situations and individuals.

Mission MCA

178

Mission MCA

8.2.4 Managing the Project Team

In addition to developing the project team, the project manager must lead them in
performing various project activities. After assessing team performance and related in the
project manager must decide if changes should be requested to the project, or if updates
are needed to enterprise environmental factors, organizational process assets, or the
project management plan. Project managers must use their soft skills to find the best way to
motivate and manage each team member.
Tools and Techniques for Managing Project Teams
There are several tools and techniques available to assist in managingproject teams:
Observation and conversation: It is hard to assess how your team members arc
performingor how they are feeling about their work if you never sec or dis-cuss these issues.
Many project managers like to practice "management bywalking around" to physically sec
and hear their team members at work. informal or formal conversations about how a
project is going can provide crucial information for virtual workers, project managers can
still observe and discuss work and personal issues via e-mail. telephone, or other
communications media.
Project performance appraisals: Just as general managers provide performance appraisals
for their workers, so can project managers. The need for and type of project performance
appraisals will vary depending on the length of the project, complexity of the project,
organizational policies, contract requirements, and related communications. Even if a
project manager does not provide official project performance appraisals for team
members, it is still important to provide timely performance feedback. If a team member
hands in sloppy or late work, the project manager should determine the reason for this
behaviour and take appropriate action. Perhaps the tea in member had a death in the family
and could not concentrate. Perhaps the team member was planning to leave the project.
The reasons for the behaviour would have a strong impact on action the project manager
should take.
Conflict Management: Few projects are completed without any conflicts. Some types of
conflict areactually desirable on projects, Intl many are not. As described in Chapter In,
Project Communications Management, there are several ways to handle conflicts. It's
important for project managers to understand strategies for handling conflicts and to
proactively manage conflict.
Issue logs: Many project managers keep an Issue log to document, monitor, and track
issues that need to be resolved for the project team to work effectively. Issues could include
items where people have differences of opinion. situations that need !mat clarification or
investigation, or general concerns that need to be addressed. It is important to acknowledge

Mission MCA

179

Mission MCA

issues that can hurt team performance and take action to resolve them. The project
manager assigns someone to resolve each issue and assign a target date for resolution.
Interpersonal skills: As mentioned in Chapter 1, project managers must possess several
interpersonal skills. To effectively manage teams, it is especially important to focus on
leadership, influencing. anddecision making skills.
General Advice on Managing Teams
According to Patrick Lencioni, a well-known author and consultant on teams. "Teamwork
remains the one sustainable competitive advantage that has been largely untapped... teamwork is almost always lacking within organizations that fail. and often present within those
that succeed. The five dysfunctions of teams are:
1. Absence of trust
2. Fear of conflict
3. Lack of commitment
4. Avoidance of accountability
5. Inattention to results
Lencioni's books provide suggestions for overcoming each of these dysfunctions. For
example.he suggests that team members take the Myers-Briggs Type Indicator, as described
earlier in this chapter, to help people open up to each other and build trust. To master
conflict, he suggests that teams practice having unfiltered, passionate debates about
important issue. To achieve commitment, he stresses the importance of getting out all
possible ideas, getting people to agree disagree, but then having them commit to decisions.
To embrace accountability, Lencioni stresses the importance of clarifying and focussing on
everyones top priorities. He also suggests that peer pressure and the intervention. Finally,
using some type of scoreboard to focus on team result helps eliminate ambiguity so
everyone knows what it means to achieve positive result.
Additional suggestion for ensuring that teams are productive include the following:

Be patient and kin with your team. Assume the best about people, do not assume that
your team member are lazy and careless.
Fix the problem instead of blaming people. Help people work out problems by focusing
behaviors
Establish regular, effective meetings. Focus on meeting project objectives and producing
positive results.

Mission MCA

180

Mission MCA

Allow time for teams to go through the basic team-building stages of forming. Storming,
norming, performing and adjourning. Dont expect teams to work at the highest
performance level right away.
Limit the size of work teams to three to seven members.
Plan some social activities to help project team members and other stakeholders get to
know each other better. Make the social events fun and not mandatory.
Stress team each other better. Create traditions that teams members enjoy.
Nurture team members and encourage them to help each other. Identifying and provide
training that will help individuals and the team as a whole become more effective
Acknowledge individual and group accomplishments
Take additional actions rto work with virtual team members. If possible, have a face-toface or phone meeting at the start of a virtual project or when introducing a virtual team
member. Screen people carefully to make sure they can work effectively in a virtual
environment. Clarify how Virtual team members will communicate.

As you can imagine, team development and management are critical concerns on many
information technology projects. Many information technology projects managers must
break out of their rational/NT preference and focus on empathically listening to other
people to address their concerns and create an environment in which individuals and teams
can grow and prosper.

Mission MCA

181

Mission MCA

8.3 Change management

At any given time we must deal with changes that affect us. These changes may resultfrom
world or local events, the organizations we are part of, or personal decisions
andrelationships (Conner, 1995). Think about the changes that are going on in your life
rightnow. You may be graduating soon, seeking employment, moving to a new residence,
orscheduling root canal work with your dentist the day after tomorrow. The point is
thatthere are a number of changes going on in our lives at any given moment. We may
viewthese changes as being either positive or negative. As Jeanie Duck (2001)
observes,nearly all change in our lives entails some amount of anxiety. Anxiety combined
withhope is anticipation, while anxiety combined with apprehension is dread.
Whether we view change as positive (anticipation) or negative (dread), there is a
certainamount of stress that accompanies each change. For example, let's say that you
willgraduate this semester and start a new job that requires you to move to a distant
city.Although you may be looking forward to leaving school and earning some real
money,you may still feel some apprehension. After all, you will have to leave your circle of
familyand/or friends and the familiarity of your present environment. Once you arrive in
yournew city, you will need to find a new place to live, make new friends, and become
familiarwith your new job, the company, and its people. Moving to a new city is relatively
easycompared to the other transitions. The move itself is a change that will occur
fairlyquickly; the transition required to adjust to the change takes longer.In Managing at the
Speed of Change, Daryl Conner (1995) points out that anindividual must deal with a variety
of changes in his or her life and that we mustassimilate these changes over time.
Assimilation is the process of adapting to changeand determines our ability to handle
current and future change (Davidson 2002). Forexample, you may be dreading that root
canal work next Wednesday, but once it'sover you won't have the same level of anxiety that
you are feeling right now. Or, youmay be in the midst of planning a wedding. Most people
view weddings as happyoccasions, but anyone who has planned and gone through a
wedding knows it can be astressful. The stress and anxiety felt before the ceremony,
however, become a distantmemory once the happy couple celebrates their first
anniversary.
It simply takes timeto assimilate change because we must adjust to the transition. Major
changes, whetherpositive or negative, will require more time to assimilate than small ones.
But oncechange is assimilated, it no longer creates the same level of anxiety or
stress.According to Conner, the problem occurs when we cannot assimilate change
fastenough. Unfortunately, change tends to have a cumulative effect, and we can
onlyassimilate change at a given pace. Different people will assimilate change at a
differentpace, and this ability to assimilate change becomes our resiliency to handle
change.Figure 11.1 illustrates the cumulative effect of assimilating change over time.
Problemsoccur when we have to deal with too many changes or when we cannot
assimilatechange fast enough.
When an individual passes a certain threshold, heor she may become stressed out and
exhibit dysfunctional behaviors. The behaviors dependlargely on the person and may range
from mildirritability to depression or dependence on alcohol or drugs. Therefore, it is
Mission MCA

182

Mission MCA

important to manage the assimilation of change to keep thingsbelow the change threshold.
In order to do this,Change an individual may try various tactics,such asthreshold exercising
more regularly or postponing majorlife changes so as to deal more effectively with the
presentchanges.
Conner (1995) points out that organizations are made up ofpeople and these people have
any number of personal changesgoing on in their lives. Changes proposed by an
organization(e.g., reorganization, downsizing, implementing a newinformation system) will
certainly affect the way people workand the relationships that have become established.
Althoughthese organizational changes will have to be assimilated byeach person, the
organization must assimilate
SOURCE: D. Conner, Managing at the Change of Speed (New York:
Villard Books, 1995).
change similar to an individual. After all, organizations are made up of people!Therefore,
each change adopted by an organization must be assimilated and managedwithin the
change threshold. Just like people, organizations can exhibit dysfunctionalbehaviors. These
behaviors may include an inability to take advantage of new opportunitiesor solve current
problems. Eventually, an organization's inability to assimilatechange will be reflected in the
organization's ability to make a profit. Like anindividual who cannot effectively deal with
change and the associated stress, thelong-term health and sustainability of the organization
becomes questionable.
Change as a Process
Although a great deal has been written about change management, one of the mostuseful
models for understanding change was developed by Kurt Lewin. Lewin developedthe
concept of Force Field Analysis or change theory to help analyze and understandthe forces
for and against a particular plan or change initiative (Lewin 1951). AForce Field Analysis is a
technique for developing a big picture that involves all theforces in favor of or against a
particular change. Forces that are viewed as facilitatingthe change are viewed as driving
forces, while the forces that act as barriers or thatwork against the change are called
restraining forces. By understanding all of theforces that act as aids or barriers to the
change, one may enact strategies or decisionsthat take into account all of the various
interests.Lewin's basic model includes three concepts: unfreezing, changing, andrefreez-ing
as illustrated in Figure 11.2. The present state represents an equilibrium orstatus quo. To
change from the current state, there must be driving forces both to initiateand to motivate
the change. This requires an unfreezing, or an altering of the currentstate's habits,
perceptions, and stability.
Figure 11.2 also depicts a transition from the present state to the desired state. Thisstate is
sometimes referred to as the neutral zone and can be a limbo or emotionalwilderness for
many individuals (Bridges 1991). Problems arise when managers donot understand, expect,
or acknowledge the neutral zone. Those in the organizationwho act and support the driving
forces for the change may be likely to rush individualsthrough the transition. This rushing
often results in confusion on the part of those in theneutral zone, and the resisting forces
Mission MCA

183

Mission MCA

(i.e., the emotional and psychological barriers)tend to push those individuals back to their
present state. People do not like beingcaught in the neutral zone. They may try to revert
back to the original status quo orescape. Escape may mean leaving the organization or
resistance to the change initiative altogether. In addition, individualswho find themselves in
the neutral zone toolong may attempt to create a compromise inwhich only a portion of the
change isimplemented. This compromise will onlyresult in missed opportunities and sets a
badprecedence for the next change initiativeifthis one did not work, why should
anyonebelieve the next one will?People do not necessarily resist change.They resist losses
and endings. Unfreezing, ormoving from the current state, means lettinggo of something.
Therefore, viewingchange from

state. Transition through the neutral zone also means a loss of equilibrium until anindividual
or organization moves to the desired state. Once there, it is important thatthe attitudes,
behaviors, and perceptions be refrozen so that the desired state becomes thenew status
quo and equilibrium for the individuals involved.
Emotional Responses to Change
Until now, we have looked at change as a process and how change affects different areas of
the organization. Change can also bring out emotional responses. An individualmay have an
emotional response to a change when the change is perceived as asignificant loss or upsets
a familiar or well-established equilibrium. In her book OnDeath and Dying, Elizabeth KublerRoss (Kubler-Ross 1969) provides insight intothe range of emotions one may experience
from the loss of a loved one. These sameemotional responses can be applied to managing
change whenever people experiencethe loss of something that matters to them.The original
model included five stages that we go through as part of a grievingprocess that leads to
eventual healing. If people are not allowed to grieve and gothrough the first four stages, it
becomes difficult to reach the last stageacceptance.A person may have a number of
emotions, such as sorrow, loneliness, guilt, and soforth, but the inability to work through
these five stages can create more stress anddifficulties than working through the stages.
Although Kubler-Ross's model has beenwidely accepted, it has also been criticized as being
oversimplified. However, it stillprovides some valuable insight for understanding how
people may react to significantchanges that affect their lives. The five stages include:

Mission MCA

184

Mission MCA

DenialThe first stage is characterized by shock and denial. It is a common reaction when
a person is given first notice of a change that will havesignificant impact. For example, when
a person is informed that he or sheis being fired by an organization, the initial response may
be, Are you serious? This can't be true! The reality may be too overwhelming. Disbeliefmay
be the immediate defense mechanism. The initial news, however, provides a beginning for
understanding the full impact of the change that isabout to take place.
AngerOnce a person gets over the initial shock of the announcement, heor she may
become angry toward others, or even the messenger. The reaction is to blame whoever is
responsible for creating the change. Althoughanger is a more active emotional response, it
can be a cathartic expressionwhen people are allowed to vent their emotions. Keep in mind
that there isa difference between feeling anger and acting out in anger. While
havingfeelings is always acceptable, the latter never is.
BargainingIn the third stage, the person is no longer angry. In fact, he orshe may be
quite cooperative and may try to make deals in order to avoidthe change. For example, the
person who lost her job may begin makingpromises that she will "double my productivity"
or "take a cut in pay" inorder to avoid being let go. A person may look for ways to extend
the statusquo, or the present equilibrium, by trying to "work things out."
DepressionOnce a person admits that the change is inevitable, he or shemay understand
the full impact of the change and may enter the fourthstagedepression. This stage
generally occurs when there is an overwhelming sense of the loss of the status quo.
Although losing a job
involves losing income, most people become depressed because they alsolose the identity
associated with their job.
AcceptanceThe last stage is when a person comes to grips with thechange. A person
does not have to like the change in order to accept it. Thisfifth stage has more to do with
one's resolve that the change is inevitable andmust be dealt with. Acceptance is an
important part of ending the status quoand getting on with a new state.These emotional
responses can help us understand why people react the way theydo when faced with
organizational change. Because of these emotions, people may bedrained and productivity
in the organization will suffer. It is also important to understandthat people will have
different perceptions of change. But, to them, their perceptionis their reality. Often
management and the project team will have known about andhave had the time to prepare
for an upcoming change. While they may be impatient forthe change to occur, others in the
organization will lag behind. Management and theproject team may want to "get on with
it," while the others are still dealing with theiremotions during the transition. Instead of
trying to suppress these individuals and theiremotions, the leaders of change should accept
them as a normal part of

Mission MCA

185

Mission MCA

Assess Willingness, Readiness, and Ability to Change

The first step to developing a change management plan is to assess the
organization'swillingness, readiness, and ability to change. This assessment entails defining
who theplayers or stakeholders involved in the change will be, their roles, and how they
willinteract with each other (Davidson 2002). Conner (1995) defines several roles orplayers
involved in a change initiative: the sponsor, change agents, and targets.
Sponsor The sponsor can be an individual or group that has the willingness andpower, in
terms of authority and making resources available, to support the project.Although this
person or group is often the project sponsor, an initiating sponsor mayhand off the project
to a sustaining sponsor. More specifically, after making the decisionto fund and support the
project, the initiating sponsor may become completelyremoved from the project. Without
the support of a sustaining sponsor, the project willeventually lose steam and direction.
Therefore, the sustaining sponsor must become theprimary sponsor for the project. A major
portion of the organization's ability and willingnessto support the change rests with the
sponsor's commitment to the project and the associated change that will impact the
organization. This commitment may be in terms of how they communicate with the rest of
the organization, how they deal with challenges and issues, and the amount and quality of
resources made available. In addition, sponsors must be effective leaders. If the project fails
because the organization cannot adapt to the change, the project's envisioned value to the
organization is lost and the sponsor's credibility is diminished. As Conner points out, "they
lose twice."

Mission MCA

186

Mission MCA

Change Agents In the most basic terms, the change agents will be the project managerand
team; however, others from inside or outside the organization may be involvedas well. An
agent may be an individual or group responsible for making the changehappen in order to
achieve the project's goal and objectives. Change agents reportdirectly to the sponsor and
must be able to diagnose problems, plan to deal with theseissues and challenges effectively,
and act as a conduit of communication betweenthe sponsor and the targets of change. The
ability to sustain the change associated withthe IT project rests largely with the change
agents. They must be ready and properlyprepared to meet the challenges they face.
Targets The target is the individual or group that must change. In general, thesemay be the
users of the new system or those who will use or be directly involved withfinal product of
the project. Conner uses the term "target" because these are the peoplewho are the focus
of the change effort and who play a critical role in the ultimatesuccess of the
project.Although the project sponsors and change agents play important roles in
supportingand carrying out the change effort, the dynamics associated with the targets of
changebecome the most critical. Therefore, the willingness, ability, and readiness to change
alsorest largely with the change targets. This may require: (1) clarifying the real
impacts of the change, (2) understanding the breadth of change, (3) defining what's overand
what's not, and (4) determining whether the rules for success have changed.The project
team and sponsor often do not think about how the planned changeand transition will really
Mission MCA

187

Mission MCA

affect people within the organization. As described in theprevious section, change often
brings about endings and a sense of loss of control.The project team and sponsor should
take the time to think about what various individualsor groups stand to lose. For example,
perceptions of loss may include power,relationships with other people, stability, or even
control. As a result, people maybecome confused and disoriented.Change within an
organization can affect different things in different ways.Leavitt's model, as illustrated in
Figure 11.4, suggests that changes in people, technology,task, or organizational structure
can influence or impact the other areas (Leavitt1964). These four components are
interdependent where a change in one can result in achange in the others For example, a
change in the organization's technology (e.g.,implementing a new information system) can
impact the people within the organization(e.g., new roles, responsibilities, etc.) as well as
the tasks the individual's perform (i.e.,the work they perform), and the organization's
structure (i.e., formal or informal).
As a result of the planned change, people will go through a variety of emotions.On first
learning of the impending change, people may feel shock, anger, and evendenial. Later on,
they may try to bargain or negotiate as a way of maintaining stability.This time is difficult
because compromise, or appeasement, may seem to be a goodalternative for avoiding
conflict and resistance. Unfortunately, this tactic will onlyundermine the effectiveness of the
change initiative. Therefore, it is important that aboundary be defined in a way that allows
the change to happen as planned, but alsoallows individuals to "take something with them"
by giving them something familiarto hold on to so as to ease the transition. This allows the
past to be remembered withreverence and can also mark the end and the new
beginning.People become confused and disoriented when the rules for success change
orare no longer clearly defined.
Let's say that you have been working at a company forseveral years. Over that time, you
have come to understand and become part of thatculture. You know from your own
experience and from those around you that promotionis based solely on seniority. As long
as you meet the minimum performancerequirements of your job, you know that
promotions and the pay raises that followwill come arter working a specific amount ot time
m aparticular job. If the company ever has to layoffemployees, you know that layoffs will
begin with theemployees with the least seniority. But what if thecompany you work for has
been acquired by a largerorganization? The acquiring company has decided to"make a few
changes" and starts by downsizing theworkforce in your company. But now each
employee'sperformance will be reviewed and only the topperformers will be invited to stay.
You can only begin toimagine peoples' reactions. The rules for success have changed.

Mission MCA

188

Mission MCA

Figure 11.4 Leavitt's Model of Organizational Change

Develop or Adopt a Strategy for Change

Once the organization's capability to change is Figure 11.4 Leavitt's Model of Organizational
Change assessed, the next step involves developing oradopting a strategy for change.
Davidson (2002) provides four approaches tochange management.
Rational-Empirical Approach The rational-empirical approach to change managementis
based on the idea that people follow predictable patterns of behavior andthat people will
follow their own self interests. Therefore, a change agent must bepersuasive in convincing,
explaining, and demonstrating how a particular change willbenefit a particular person or
group identified as a target of the change.It is important that the individuals affected by the
change be provided with consistentand timely information. Consistent information means
that the project teamand sponsor send the same message to all individuals and groups
throughout theorganization. Mixed messages can lead to confusion and suspicion.
Credibility shouldnot become suspect. In addition, each message must be accurate and
timely. Often the excuse is, "It may be better to wait until we have all the details." But,
saying nothing atall can send the wrong message.When people are not given enough
information, they tend to seek informationfrom other sources. Often these sources rely on
innuendos, misinformation, and opinions,which become gossip that spreads through the
informal organization. Stress levelsrise until a point is reached where the organization becomes
dysfunctional. It is betterto be honest and tell people that there is no news before the rumor mill goes
into warpdrive.

Many managers believe that it is better to spare people bad news until the verylast
moment. However, it may be better to give people enough advanced warning toallow them
to prepare for any upcoming changes. Then they can deal effectively withthe gamut of
emotions that will be brought on by the change.The change management plan based on this
Mission MCA

189

Mission MCA

strategy should provide each individualwith the purpose, a picture, and a part to play.
Purpose is the reason for the change.Often individuals within the organization have a
narrow view of their job and its relationshipto the rest of the organization. It may be useful
to provide people with achance to see or experience the problem or opportunity first-hand.
For example, a personmay be given the chance to witness how the current level of poor
service is affecting theorganization's customers. Then, it should be clear to that person that
unless theorganization does something (i.e., implement a new information system), it will
continuelosing customers to its competition. In time, the company will have to reduce
itsworkforce or inevitably face bankruptcy.
A picture, on the other hand, provides a vision or a picture in the individual's mind as to how
the organization will look or operate like in the future. If done effectively,this procedure can
help the individual buy into the proposed change.A part to play can be very effective in
helping the individual become involved inthe proposed change. Although purpose and a
picture of the proposed change areimportant, it is also important for the individual to
understand and visualize the parthe or she will play once the change is instituted. Having a
part may provide theneeded WIIFM (or what's in it for me?) to help them through the
transition.
Normative-Reeducation Approach The normative-reeducation strategy forchange
management is based on the work of Kurt Lewin. This approach takes thebasic view that
people are social beings and that human behavior can be changed bychanging the social
norms of a group. Instead of trying to change an individual, onemust focus on the core
values, beliefs, and established relationships that make up theculture of the group. For
example, you may hear, "That's the way things are donearound here." The targets of change
in this case may be highly resistant to new ideas ornew ways of doing things.
This approach can be very difficult and time-consuming because the change agents and
sponsor must study the existing values and beliefs of a group. It requiresunfreezing the
current norms so that the change can take place and so that a new set ofnorms can be
refrozen in order to solidify the acceptance of the new way of doingthings by the group. As a
result, change becomes more effective when each personadopts the beliefs and values of
the group. The focus for managing change under thisstrategy becomes helping people
redefine their existing social norms into a new setthat supports the change effort. Some key
principles include:
Capacity for change is directly related to a person's participation in agroup. When we
become part of a group, our views and beliefs and those ofthe group become interwoven
with each other.
Effective change requires changing something not only about the individual's values and
beliefs, but also the values and beliefs that make up theexisting group's culture.
Bias and prejudice toward guarding one's closely held beliefs and valuesdiminishes one's
ability to think rationally. Even when presented with thefacts, many people may not act
upon them in a rational way.

Mission MCA

190

Mission MCA

Power-Coercive Approach The power-coercive approach to change managementattempts to

gain compliance from the change targets through the exercise of power,authority, rewards,
or threat of punishment for non-conformance. Many managers maybe lured into using this
deceptively easy and straightforward approach, but there is areal risk when used in the
wrong situation. People may comply (or at least go throughthe motions of compliance), but
an approach based solely on rewards or punishment
may have only short-term effect. For example, a person may comply for the timebeing, until
they can find new employment. On the other hand, a person may view thechange as
temporary and just "wait out the storm" until it is convenient or safe to goback to the old
way of doing things.There are, however, situations where the power-coercive approach is
useful andeffective. In such cases, the targets of change recognize the legitimate power or
expertiseof the change agent. For example, a person may not change his indolent lifestyle
untilthe doctor cautions him that certain health problems will get worse unless he
changeshis diet and begins an exercise program.
Similarly, an organization may be faced with asituation that requires immediate attention
i.e., any inaction or time lost trying to get"everyone onboard" would spell disaster for the
company. In this case, the use of rewardsand threats would be a rational approach. As
Davidson observes,People's dependency on an organization largely dictates how
effectivethe power-coercive approach and the use of sanctions can be. Ifpeople are highly
dependent on the organization; live paycheck topaycheck; have few job alternatives; and
are not financially, mentally,or emotionally prepared to walk, you are on relatively
safeground using the power-coercive approach judiciously. (90-91)The objective is to
change the behaviors of the targets so that their new behaviorsupports the change effort.
Davidson points out that sanctions should be imposed onan individual level and should
focus on what an individual values and what they dread
losing perhaps a bonus, a paycheck, or a position within the organization. Sanctionscan
be imposed in ascending order to demonstrate a point in the beginning and to keepany
target's losses at a minimum. A change agent or sponsor can lose credibility, however,if they
issue a warning or sanction that they do not fully intend to carry out.Finally, the change
agent or sponsor should never be abrasive or disrespectful andshould not impose sanctions
in a cruel or vindictive manner.
Environmental-Adaptive Approach Like a pair of old, comfortable shoes, peopleoften
become attached to and comfortable with a certain way of doing things, perhapsan older
system or established processes that have become part of the group's cultureand norms.
The premise of the environmental-adaptive approach is that althoughpeople avoid
disruption and loss, they can still adapt to change.Following this approach, the change agent
attempts to make the change permanentby abolishing the old ways and instituting the new
structure as soon as possible.Cortez, the explorer, probably displayed the most drastic form
of this approach. Afterlanding in the New World, many of his men began to grumble about
the conditionsand what lay ahead. In response, Cortez burned the boats so that there was
no optionother than pressing on. A much less drastic example would be upgrading
everyone'sword processing software over the weekend so that when everyone returned to

Mission MCA

191

Mission MCA

workon Monday morning, they would have no choice but using the new software
package.In both examples, the targets of change were given no choice but to change.
Although this approach may be effective in certain situations, it is still importantthat the
targets of change assimilate the change as quickly as possible in order to adapt tothe change
as soon as possible. Some ways may include helping the targets of changesee the benefits
and showing them how the new way is similar to their old, familiarway of doing things.
The change management strategies introduced here are typical for many changeinitiatives.
A single strategy or approach, however, may not be effective in every situation.A more
useful approach may be to combine the different strategies, dependingon the impact of the
change and the organization.

Implement the Change Management Plan and Track Progress

Once the players and the strategy for the change management plan have been defined,the
next step entails implementing the change management plan and tracking itsprogress.
Although tracking progress should be integrated into the overall project planand monitored
using the various project tools, such as the Gantt chart, PERT chart, and soforth, introduced
in an earlier chapter, milestones and other significant events should beidentified and used
to gauge how well the organization is adapting to the change.In addition, one of the most
critical issues for ensuring that the change takes placeas planned is the establishment of
effective lines of communication. At the very outsetof any change initiative, gossip, rumors,
and people's perceptions will find their wayin both the formal and informal organizations. It
is important that the project teamand project sponsor create and open channels of
communication.The communication media can be important, especially when delivering
certaintypes of news.
For example, a richer media, such as face-to-face communication, isgenerally preferable
when delivering important or bad news. There are a number ofstories about people who
realized that they were being let go when they found theirphone line and network
connections disconnected and security guards standing bytheir desk waiting to escort them
out of the building. Delivering bad news is somethingthat no one really enjoys, but must be
done nonetheless. The point is that managementcan handle difficult situations with class or
with very little class.Finally, open channels of communication should be both ways. The
project teamand sponsor must communicate effectively with the various groups within the
organizationaffected by the change, and these groups, in turn, must be able to
communicateeffectively with the project team and sponsor. In addition, Web sites, e-mails,
memos,and newsletters can all be mediums for effective communication.
Evaluate Experience and Develop Lessons Learned
As the project team carries out the change management plan, they will, no doubt, learn
from their experiences. These experiences should be documented and made available to
other team members and other projects so that experiences can be shared and best
practices
can be identified. At the end of the project, it is important that the overall success of
Mission MCA

192

Mission MCA

the change management plan be evaluated. This evaluation may help determine the
effectiveness
of the different players or a particular change management strategy. The important
thing is to learn from experience and to share those experiences with others while
adding new form and functionality to the project organization's IT project methodology.

8.3.1 Dealing with Conflict & Resistance Leadership & Ethics

Resistance and conflict are a natural part of change (Davidson 2002). In this section, we will
look at the nature of resistance and conflict and several approaches for dealing with these
two issues. Keep in mind that the concept of conflict presented in this section can be
applied to conflicts within the project team as well as external conflicts brought about by
the change effort.
Resistance
Resistance should be anticipated from the outset of the project. Rumors and gossip will add
fuel to the fire, and the change effort can easily run out of steam if those affected by the
change begin to resist. Resistance can be either overt, in the form of
Conflict
memos, meetings, etc., or covert, in the form of sabotage, foot dragging, politicking, etc.
Once the change is compromised, management and the project team will lose credibility,
and the organization may become resistant to all future changes. Resistance can arise for
many valid reasons. For example, someone may resist an information system because the
response time is too slow or because it does not provide the features or functionality that
were originally specified as part of the requirements. On the other hand, resistance due to
cultural or behavioral reasons is harder to rationalize, but still can keep a project from
reaching its intended goal. People may resist change even though they understand that the
change will be beneficial (Davidson 2002). For example:
Some people perceive the change as requiring more time and energy than they are willing
to invest.
Sometimes people feel that that a change will mean giving up something that is familiar,
comfortable, and predictable.
People may be annoyed with the disruption caused by the change, even ifthey know that
it will be beneficial in the long run.
People may believe that the change is being imposed on them externally, and their egos
will not tolerate being told what to do.
In addition, people may resist because of the way the decision to change was announced
or because it was forced upon them.
Resistance is human nature and a natural part of any change process. Understanding what
an individual or group perceives as a loss is the first step to dealing with resistance
effectively. Because the project team and sponsor are the agents of change, it is easy to see
Mission MCA

193

Mission MCA

those who resist as overreacting or not being logical. As the proponents of change, the
project team and sponsor have had the luxury of knowing about the change early and,
therefore, have had the time to become used to it. The rest of the organization, however,
may learn about the change much later and, therefore, may not be at the same place for
digesting the change.
Subsequently, it is important that the project team and sponsor listen to what the rest of
the organization is saying. Instead of arguing and trying to reason, it is better to allow
people to vent their anger and frustration. Again, having defined a boundary of what is and
what is not part of the change can help deal with stressful conflict situations. Keep in mind
that empathizing or sympathizing with an individual is not the same as agreeing with them.
Closely associated with resistance is the concept of conflict.
Conflicts arise when people perceive that their interests and values are challenged or not
being met. Conflictmanagement focuses on preventing, managing, or resolving conflicts.
Therefore, it is important to identify potential conflicts as early as possible so that the
conflict can be addressed. Although conflict can be positive and help form new ideas and
establish commitment, negative conflict left unresolved can lead to damaged relationships,
mistrust, unresolved issues, continued stress, dysfunctional behavior, and low productivity
and morale (Davidson 2002). As Verma (1998) suggests:
Although conflict is one of the things most of us dislike intensely, it is inevitable. Most often
when we try to avoid conflict, it will nevertheless seek us out. Some people wrongly hope
that conflict will go away if it is ignored. In fact, conflict ignored is more likely to get worse,
which can significantly reduce project performance. The best way to reduce conflict is to
confront it. (367)
There are three different views of conflict that have evolved from the late nineteenth
century to today (Verma 1998). These views are
(1) the traditional view (mid-nineteenth century to mid-1940s),
(2) thecontemporary view (mid-1940s to 1970s), and
(3) theinteractionist view (1970s to present).
Traditional ViewThe traditional view considers conflict in a negative light and feels
conflict should be avoided. Conflict, according to this view, leads to poor performance,
aggression, and devastation if left to escalate. Therefore, it is important to manage conflict
by suppressing it before it occurs or eliminating it as soon as possible. Harmony can be
achieved through authoritarian means, but the root causes of the conflict may not be
adequately addressed.
Contemporary ViewThe contemporary view, on the other hand, suggests that conflict is
inevitable and natural. Depending on how conflict is handled, conflict can be either positive
or negative. Positive conflict among people can stimulate ideas and creativity; however,
negative conflict can have damaging effects if left unresolved. Therefore, positive conflict
should be encouraged, while keeping negative conflict in check.

Mission MCA

194

Mission MCA

Interactionist ViewToday, the interactionist view holds that conflict is an important and
necessary ingredient for performance. Although the contemporary view accepts conflict, the
interactionist view embraces it because teams can become stagnant and complacent if too
harmonious or tranquil (Verma 1998). Subsequently, the project manager should
occasionally stir the pot in order to encourage conflict to an appropriate level so that people
engage in positive conflict. This may, however, be a fine line to walk for many project
managers. Although someone who plays the role of the devil's advocate can be effective in
many situations, people may become annoyed when it is used in every situation or used
ineffectively. To better understand the nature of conflict, Verma(1998) points out that
conflict within projects can fit one, or a combination, of three categories:
1. Conflicts associated with the goals, objectives, or specifications of the project.
2. Conflicts associated with the administration, management structures, or underlying
philosophies of the project.
3. Conflicts associated with the interpersonal relationships among people based on work
ethics, styles, egos, or personalities. According to a study conducted by Thomas and Schmidt
(Thomas and Schmidt 1976), a typical middle or top-level manager spends about 20 percent
of her or his time dealing with conflict! For the project manager and project team, the seeds
of resistance can easily lead to negative conflicts. Subsequently, it is important to
understand how to deal with conflict. Blake and Mouton (Blake and Mouton 1964) and
Verma (1998) describe five approaches for dealing with conflict. A project team member or
project manager should choose an appropriate approach for managing conflict based on the
situation.
AvoidanceAvoiding conflict focuses on retreating, withdrawing or ignoring conflict.
Sometimes, a cooling-off period may be a wise choice, especially when emotions and
tempers are high. Avoidance may be appropriate when you can't win, the stakes are low, or
gaining time is important. However, it may not be useful when the immediate, successful
resolution of an issue is required.
AccommodationAccommodation, or smoothing, is an approach for appeasing the
various parties in conflict. This approach may be useful when trying to reach an overall goal
when the goal is more important than the personal interests of the parties involved.
Smoothing may also be effective when dealing with an issue that has low risk and low return
or when in a no-win situation. Because accommodation tends to work only in the short run,
conflict may reappear in another form later on.
ForcingWhen using this approach, a person uses his or her dominant authority to
resolve the conflict. This approach often results in a one-sided or win-lose situation in which
one party gains at the other's expense. This approach may be effective when no common
ground exists, when you are sure you are right, when an emergency situation exists, or
when time is of the essence. Forcing resolution may, however, cause the conflict to
redevelop later because people dislike having a decision or someone else's views imposed
upon them.
CompromiseCompromise includes aspects of both forcing and accommodation; it gives
up more than forcing and less than accommodation. Compromise is essentially bargaining
Mission MCA

195

Mission MCA

one person or group gives up something in exchange for gaining something else. In this case,
no party actually wins and none actually loses, so that some satisfaction is gained from
resolution of the conflict. This approach may be useful when attempting to resolve complex
problems that must be settled in a short time and when the risks and rewards are
moderately high. Unfortunately, important aspects of a project may be compromised as a
means of achieving short-term resultsfor example, quality standards may be
compromised in order to meet the project's schedule.
CollaborationWhen the risks and benefits are high, collaboration may be the best
approach for dealing with conflict. This approach requires con fronting and attempting to
solve the problem by incorporating different ideas, viewpoints, and perspectives. The focus
of collaboration is learning from others and gaining commitment, trust, respect, and
confidence from the various parties involved (Verma 1998). Collaboration takes time and
requires a sincere desire to work out a mutually acceptable solution. In addition, it requires
a willingness to engage in a good-faith problem-solving process that facilitates open and
honest communication. According to Verma (1998), each conflict situation is unique and the
choice of an approach to resolve conflict depends on:
Type of conflict and its relative importance to the project.
Time pressure to resolve the conflict.
Position of power or authority of the parties involved.
Whether the emphasis is on maintaining the goals or objectives of the project or
maintaining relationships.
HOW TO HANDLE CONFLICT
Kenneth Cloke is the director of the Center for Dispute Resolution, and Joan Goldsmith is an
organizational consultant and educator. Together they provide a number of ideas to help
make the most of conflict. The following steps can help you to think about yourself, your
opponent, and your conflict:
1. Look inwardThe first thing to do is to focus on yourself by making a decision to
approach and engage in conflict constructively. Being open to learning during the process
and being committed to resolving the conflict constructively arerequired.
2. Set the stage for dialogThe next step is to find a neutral environment, perhaps by
inviting your opponent to lunch or some other locale away from the office. It is important to
be open, honest, and friendly rather than hostile or suspicious.
3. Listen carefullyNow is the time to disengage from your fight-or-flight response and be
open to listening empathically to your opponent. Conflict is fundamentally a communication
problem, and to be an effective listener you need to control your emotions. Control your
anger and refuse to take comments personally.
4. Speak carefullyYour needs and self-interests should be stated clearly and without
emotion. Becoming angry yourself can escalate the conflict and diminish your integrity and
credibility.
Mission MCA

196

Mission MCA

5. Dig deeperLook beyond the words spoken to the real meaning of what is being said.
This can help you to understand the underlying reasons for the conflict. Often the conflict is
not about the issue you are arguing about, but about issues that lie beneath the surface.
6. Don't get personalPeople often think that they are right and that the other person is
reason for the conflict. Conflict can present opportunities when you separate the person
from the problem, focus on the future and not the past, and stop arguing about what you
want and instead talk about why you want something. Positions that focus on what you
want limit thinking, perceptions, and imagination, while interests that focus on why you
want something can broaden choices and focus on the future.
7. Think creativelyIt helps to work with the other person to brainstorm potential solutions.
When in conflict, it is easy to spend a great deal of time trying to get the other person to
accept your solution while poking holes in theirs. Brainstorming allows for expanding the
range of solutions and seeing the big picture.
8. CollaborateIt is better to negotiate collaboratively than aggressively. Negotiating can
help both parties to shift from anger to problem solving.
9. Use the right toolsAppropriate problem-solving techniques, mediation, and so forth can
help over come an impasse, find common ground, and reach a resolution to the conflict.
10. Be forgivingLetting go of your judgments and perceptions about the other party can
help you to
improve your own skills at handing his or her difficult behaviors. Sometimes you have to
admit to yourself that you do not know how to respond effectively to his or her behaviors.
You may have to learn to let go of your conflicts so that your future is not overshadowed by
what has happened in the past. Your lessons learned from your experiences should help you
to "remember and forgive" rather than "forgive and forget."
11. Don't surrenderYou cannot always avoid conflict, but you can turn conflicts into
collaboration and opportunity. Resolving a conflict does not mean losing or giving in
because both parties cheat themselves out of the chance to learn from what the conflict has
to teach.
12. Look outwardIt is important to recognize that larger organizational and social issues
are expressed as a result of conflict. Conflict can lead to change that offers the promise of a
better world. Your role in this change can allow you to grow and feel connected with others.
13. Search for completionConflicts will continue if you do not feel that you have been
heard or have communicated completely what you think. You can help the other party by
summarizing what the other person has said, asking them to summarize what you have said,
and ensuring that the person (or you)
has not held anything back. Only then can you feelas though something has changed.

Mission MCA

197

Mission MCA

Polarity Management
Often the project manager or project team is faced with a conflict situation that appears to
have no solution. For example, the agents of change (i.e., the project team) may be faced
with conflict and resistance from the targets of change (i.e., the users). Often one side finds
itself advocating a change (e.g., a new system), while the other side is trying to maintain the
status quo. The problem is that both sides end up in a polarity where each side can only see
the upsides or advantages of their pole and the downsides or disadvantages of the other.
For many, this is a difficult dilemma that can create even more resistance and conflict. In his
book, Polarity Management: Identifying and Managing Unsolvable
Problems, Barry Johnson (Johnson 1996), advocates a technique that can help people see
the whole picture and then structure the process of change to bring about an effective
method for collaboration. According to Johnson, the problem is that we often frame a
problem or dilemma as something that can be solved by choosing one side over another.
Crusaders are those who want to change the status quo and are the supporters of change.
Tradition Bearers are those at the opposite end of the pole and wish to preserve the best of
the past and present. Using a tool called polarity mapping, we can see the upsides and
downsides that each side is advocating.
Figure 11.5 provides an example of a polaritymap for implementing a new word processing
application.The polarity map illustrated in Figure 11.5 shows how the two polarities can
bemapped. In the upper left quadrant, the Tradition Bearers' (TB+) view of the upsides
forkeeping the current word processing software package are listed, while the
Crusaders'(C+) view of the upsides for upgrading to a new word processing package are
listed in theupper right quadrant. Often the conflicts occur in the lower two quadrants or on
the diagonals.For example, people who advocate upgrading to a new word processing
packagemay focus on the upsides of the upper right quadrant (C+) and the downsides of the
lowerleft quadrant (C-). Similarly, those in favor of maintaining the status quo will focus on
thequadrants TB+ and TB-.
Often the upside of one quadrant (e.g. "familiarity" in TB+)becomes a downside in the
opposite quadrant (e.g., "will take time to learn" in TB-).Subsequently, resistance and
conflict only escalate unless both sides see the entire picture.Brainstorming is a useful
technique for having both the Tradition Bearers and theCrusaders list the upside and
downsides for both polarities. Starting in any quadrant isfine, and either side can add to the
upsides or downsides of any quadrant. It isimportant to see the big picture and for both
sides to communicate a particular perception.Johnson suggests that before using polarity
management, both sides should:
1. Clarify what you value and what you do not want to lose.
2. Let the other side know that you are aware of the downsides of the pole you favor.
3. Assure the other side that you want to maintain the upsides of their pole. The effective
use of polarity mapping helps people get away from seeing their initiative as the only
solution to the problem and from believing a decision must choose one pole over the other.
In fact, both Crusaders and Tradition Bearers make important contributions to the process.
For example, Crusaders contribute by identifying the downsides of the current pole and
Mission MCA

198

Mission MCA

provide the energy to move away from the current pole. Similarly, Tradition Bearers, by
identifying the upsides of the current pole, help identify things that should be preserved.
Tradition Bearers also identify downsides of the opposite pole. Everyone's concerns are
valid and important in coming up with amutually agreeable solution. Those advocating the
change are forced to recognize that an initiative can only be successful if the old system's
upsides are carried forward in the new environment.
The key to polarity management is recognizing that both polarities must be managed
simultaneously. The goal of the Tradition Bearers and Crusaders then becomes coming up
with ways of pursuing the upsides, while attempting to avoid the downsides. Following our
word processing example, it seems that the Tradition Bearers feel that learning a new
system may create a distraction or interruption. If upgrading to a new word processing
package, both groups may try to come up with training plan flexible enough so that both
groups get what they want. For example, training could be phased in over time, with the
early training phases covering only the basic features and functionality of the new system.

Figure 11.5 Polarity Mapping

Mission MCA

199

Mission MCA

Unit IX :The Project Implementation Plan and Closure

9.1 Project ImplementationAdministrative Closure
At some point, testing is complete and the project team and project manager thenbecome
responsible for ensuring that the information system is transferred successfullysponsoror
customer's organization. This transfer requires a tactical approach, and it can be astressful
time for all the stakeholders involved. Choosing an inappropriate implementationapproach
can negatively impact the project's remaining schedule and budget. Ingeneral, the project
team can take one of three approaches for implementing the informationsystem. These
approaches include
(1) direct cutover,
(2) parallel, and
(3) phased.
Direct Cutover
The direct cutover approach, as illustrated in Figure 12.1, is an approach where theold
system is shut down and the new system is turned on. In general, a target, or golive, date is
agreed upon, and the new system simply replaces the old.This approach can be effective
when quick delivery of the new system is criticalor when the existing system is so poor that
it must be replaced as soon as possible.Direct cutover may also be appropriate when the
system is not mission criticali.e.,the system's failure will not have a major impact on the
organization. It is important,however, that the new system be thoroughly tested so
everyone is confident that few, ifany, major problems will arise.
Although there are some advantages to using the directcutover approach, there are also a
number of risks involved thatgenerally make this the least favored approach except in a
few,carefully planned situations. Although the direct cutover approachcan be quick, it may
not always be painless. You might think of thisapproach as walking a tightrope without a
safety net. You may getfrom one end of the tightrope to other quickly, but not without
agreat deal of risk. Subsequently, there may be no going back oncethe old system is turned
off and the new system is turned on. As aresult, the organization could experience major
delays, frustratedusers and customers, lost revenues, and missed deadlines. Thepressure of
ensuring that everything is right or having to deal withproblems and irate users or project
stakeholders can create a greatdeal of stress for the project team.

Mission MCA

200

Mission MCA

Parallel
As Figure 12.2 illustrates, the parallel approach to implementation allows the old andthe
new systems to run concurrently for a time. At some point, the organizationswitches
entirely from the old system to the new.The parallel approach is appropriate when
problems or the failure of the systemcan have a major impact on the organization. For
example, an organization may beimplementing a new accounts receivable package. Before
switching over completelyto the new system, the organization may run both systems
concurrently in order tocompare the outputs of both systems. This approach provides
confidence that the newsystem is functioning and performing properly before relying on it
entirely.Although the parallel approach may not be as stressful for the project team as
thedirect cutover approach, it can create more stress for the users of the system. Theusers
will probably have to enter data into both systems and even be responsible forcomparing
the outputs. If the new system performs as expected, they may be willingto put up with the
extra workload until the scheduled target date when the newsystem stands alone. If,
however, unexpected problems are encountered, the targetdate for switching from the old
to the new system may be pushed back. The extraworkload and overtime hours may begin
to take their toll and pressure for theproject team to "get on with it" may create a stressful
environment for everyone
involved.

Mission MCA

201

Mission MCA

Phased
Following the phased approach, the system is introduced in modulesor in different parts of
the organization incrementally as illustrated inFigure 12.3. For example, an organization
may implement anaccounting information system package by first implementing thegeneral
ledger component, then accounts payable and account receivable, and finally payroll.The
phased approach may be appropriate when introducing a softwaresystem to different areas
of the organization. When upgrading anoperating system, for example, the IT department
may perform theupgrade on a department-by-department basis according to a
publishedschedule. In this case, a target date for each department would be set toallow
each department to plan for the upgradeaccordingly. A phased approach may also allow the
project team to learn from its experiences during theinitial implementation so that later
implementationsrun more smoothly.Although the phased approach may take moretime
than the direct cutover approach, it may be lessrisky and much more manageable. Also,
overlyoptimistic target dates or problems experiencedduring the early phases of
implementation maycreate a chain reaction that pushes back thescheduled dates of the
remaining plannedimplementations.
Table 12.1 provides a summary of each of the threeimplementation approaches discussed.

Mission MCA

202

Mission MCA

As the end of the project draws near, everyone may become anxious
anxious to finish theproject
and move onto other things. Unfortunately, there is often a great deal of workthat still
needs to be completed. Delays or unanticipated problems may require additionaltime and
unbudgeted resources, leading to cost and schedule overruns
overruns or extraunpaid effort,
especially if an implied warranty exists (Rosenau 1998).During the final stages of the project,
the project team may be faced with bothtime and performance pressures as the project's
deadline looms in the near future. Onthe other
other hand, the sponsor or client may become
more concerned about whether thetime and money spent on the project will reap the
envisioned benefits. The projectmanager is often caught in the middle attempting to keep
the project team happy andon track, while assuring the project sponsor that all is well.

Mission MCA

203

Mission MCA

9.2 Administrative Closure

Although all projects must come to an end, a project can be terminated for any numberof
reasons. Gray and Larson (2000) define five circumstances for ending a project:normal,
premature, perpetual, failed, and changed priorities.
NormalA project that ends normally is one that is completed as planned.The project
scope is achieved within the cost, quality, and schedule objectives,although there probably
was some variation and modification along the way.The project is transferred to the project
sponsor, and the end of the project ismarked with a celebration, awards, and recognition for
a good job well doneby those involved. As you might suspect, this is an ideal situation.
PrematureOccasionally, a project team may be pushed to complete aproject early even
though the system may not include all of the envisionedfeatures or functionality. For
example, an organization may need to have anew system operationalwith only a core set
of original requirements torespond to a competitor's actions, to enter a new market early,
or as a resultof a legal or governmental requirement. Although there is pressure to finishthe
project early, the risks of this decision should be carefully thoughtthrough by all the project
stakeholders.
PerpetualSome projects seem to take on a "life of their own" and areknown as runaway,
or perpetual, projects. These projects never seem to end.Perpetual projects may result from
delays or a scope or MOV that was neverclearly defined or agreed upon. Then, the project
sponsor (or even the team)may attempt to add on various features or functionality to the
system, whichresults in added time and resources that increase the project schedule
anddrain the project budget. Some runaway projects result from an organizationnot making
the appropriate decision to "pull the plug" on an unsuccessfulproject. The decision to
terminate a project is not an easy one if egos and perhaps even careers or jobs are on the
line. This phenomenon may also occurwhen the project has a high payoff to the
organization and when admitting tofailure is strongly against the corporate culture (Keil
1995). No matter whatthe cause, project resources are eventually drained to a point where
a potentially successful project becomes unsuccessful (Nicholas 1990). Attention todefining
and agreeing to the project's MOV, the project scope processes, andtimely project reviews
can reduce the risk of perpetual projects.
FailedSometimes projects are just unsuccessful. In general, an IT projectfails if
insufficient attention is paid to the people, processes, or technology.Even though the
project's MOV may define the project's value to theorganization, cost and schedule
overruns may drain the project's value to apoint where the costs of completing the project
outweigh the benefits.
Changed PriorityIn some circumstances, a project may be terminated as aresult of a
change in priorities. Financial or economic reasons may dictatethat resources are no longer
available to the project. Or, management maydecide to divert resources to higher priority
projects. This change can happenwhen the original importance or value of the project was
misjudged or misrepresented or when organizational needs or technology change over
thecourse of a long-term project. Some projects are "terminated by starvation."As Meredith
Mission MCA

204

Mission MCA

and Mantel (2000) describe it, successive budget cuts over timecan slowly starve a project
budget to the point where it is ended but the termination is masked. Senior management
may not want to admit that it hadchampioned a failed project or that a project will be
unsuccessful in meeting itsgoals. The project budget receives a large cut or a series of
smaller cuts. Theresult is that the project will eventually die and the project resources will
bereassigned, even though the project is never officially closed.Ideally, a project is closed or
terminated under normal circumstances. The projectachieves its desired goal and
objectives. The project sponsor is delighted with the
project's product and shows his or her delight by paying for the invoiced project workon
time and contracts for more work in the future. Unfortunately, closing a projectdoes not
often happen this way. As J. Davidson Frame (1998) points out, the projectmanager and
team should be prepared to deal with the following realities:
Team members are concerned about future jobs. Often the members of theproject team
are borrowed from different departments or functional areas ofthe organization. Once the
project is finished, they will return to their previousjobs. For consulting firms, the project
team members will move from oneproject to the next as part of their career path.
Regardless, as the project nearsits end, these project team members may begin to wonder
what they will donext. For some, there will be a rewarding life after the projectfor others
itmay mean looking for new jobs. For many it may mean disrupting aclose-knit relationship
with other members of the project team (Meredith andMantel 2000). Therefore, project
team members may become preoccupiedwith moving on with their lives and the project at
hand may become a lesserpriority. As a result, the project team members may not focus on
what has tobe done to close the project, and wrapping up the project may be a challenge.
Bugs still exist. Testing the information system is an important process ofsystems
development. However, software quality testing may not find allthe defects, and certain
bugs may not become known until after the systemhas been implemented. The appearance
of these problems can be frustratingand stressful to all the project stakeholders. Unless
these defects and bugsare promptly addressed and fixed, the project sponsor's satisfaction
withthe project team and the information system may become an issue.
Resources are running out. Resources and the project schedule are consumed from the
project's earliest inception. At the end of the project, bothresources and time remaining are
usually depleted. As unanticipated issues,problems, or challenges arise, the project manager
may find that adequateresources to deal with these events effectively are not available. The
projectmanager may find his or her situation aggravated if management decides tocut or
control the project's budget.
Documentation attains paramount importance. Information technology projects have
numerous documentation requirements. They require project, system, training, and user
documentation. Under ideal circumstances, the time towrite documentation is built into the
project plan and completed throughoutthe project. Many times, however, documentation is
put off until the end of theproject. As the end draws near, documentation becomes
increasingly important. As a result, documentation may require more time and resources to
complete, or shortcuts are taken to remain within the current project constraints.

Mission MCA

205

Mission MCA

Promised delivery dates may not be met. Most projects experience scheduleslippage. This
slippage may be due to poor project management, implementation risks, competitive
requirements, or overly optimistic estimates. project will require a certain amount of
resources and a certain amount oftime to complete. Any misjudgment concerning what has
to be done, whatis needed to complete the job, and how long it will take will result in
avariance between the planned and actual schedule and budget. The players may possess a
sense of panic. As schedules begin to slip and project resources become depleted, various
project stakeholders may experience asense of alarm. The mangers or partners of a
consulting firm may worry thatthe project will not be profitable or satisfactory to the
customer. The sponsoror customer may worry that the information system will not be
delivered ontime and within budget or provide the expected value to the organization.
Moreover, the project manager and team may also be worried that the projectwill not be
successful and the blame will rest squarely on their shoulders. Asthe sense of panic
increases, the chances for an orderly closeout grow dim.Regardless of whether a project
ends normally or prematurely, it is important thatan orderly set of processes be followed in
order to bring it to closure. A good close-outallows the team to wrap up the project in a
neat, logical manner. From an administrativeview, this procedure allows for all loose ends to
be tied up. From apsychological perspective, it provides all of the project stakeholders with
a sense thatthe project was under control from the beginning through to its end (Frame
1998).
Project Sponsor Acceptance
The most important requirement for closure under normal circumstances is obtainingthe
project sponsor's acceptance of the project. Delivery, installation, andimplementation of the
information system do not necessarily mean that the projectsponsor or client will accept the
project's product. Since acceptance depends heavilyon the fulfillment of the project's scope,
the project manager becomes responsible fordemonstrating that all project deliverables
have been completed according tospecifications (Wysocki, Beck et al. 1995). Ancillary items,
such as documentation,training, and ongoing support, should not be afterthoughts. These
items should havebeen included in the original scope of the project. Any attempt to
renegotiate what isand what is not part of the project work at this late stage of the project
can create illfeelings or hold up payment by the client (Rosenau 1998).Rosenau (1998)
observes that there are two basic types of project sponsors.Shortsightedsponsors tend to
view the project as a short-term buyer-seller relationshipin which getting the most for their
money is the most important criteria for acceptingthe project. This view often leads to an
adversarial relationship if the sponsor attemptsto renegotiate the project scope or price at
the end of the project.
Knowledgeable sponsors realize that they have an important stake in the outcomeof the
project. As a result, they will be actively involved throughout the project in aconstructive
manner. As Rosenau points out, knowledgeable sponsors may ask toughquestions during
project reviews, but their objective is not to embarrass the projectteam or manager, but to
ensure the success of the project. Instead of an adversary tryingto get the most in a "winlose" situation, the knowledgeable sponsor will negotiateintelligently and in good faith.

Mission MCA

206

Mission MCA

Regardless of whether the sponsor is short-sighted or knowledgeable, the projectmanager

and team can improve the likelihood that the project will be accepted if they(1) clearly
define the acceptance criteria for the project at the early stages of the project,and (2)
document the completion of all project deliverables and milestones.A clear definition of the
project deliverables is an important concern for projectscope management (discussed in an
earlier chapter). Yet, defining and verifying thatthe project scope and system requirements
are accurate and complete is only one component.Having scope change procedures in place
that are understood by all the projectstakeholders also ensures that everyone has the same
expectations concerning whatwill and what won't be delivered at the end of the project.The
IT project methodology incorporated in this text also focused on managingthe project based
on phases that focus on specific deliverables. Project milestonesensure that the deliverables
are not only complete, but completed right. Documentingeach deliverable and milestone
throughout the project provides confidence to theproject sponsor that the project has been
completed fully.
The Final Project Report
In general, the project manager and team should develop a final report and presentationfor
the project sponsor and other key stakeholders. The objective of the report andpresentation
should be to give the project sponsor confidence that the project has beencompleted as
outlined in the business case, project charter, and project plan. By gainingthis confidence,
the sponsor or client will be more likely to formally accept the projectthat will allow for a
smooth termination of the project.The report may be circulated to key stakeholders before
the presentation in orderto get feedback and to identify any open or unfinished items that
need to be scheduledfor completion (Rosenau 1998; Buttrick 2000). Once finalized, the final
project reportprovides a background and history of the project. The report should include
and discuss
the following areas at a minimum:
Project Summary
Project Description
Project MOV
'- Scope, Schedule, Budget, and Quality Objectives
Comparison of Planned versus Actual
1 Original Scope and history of any approved changes Originalscheduled deadline versus
actual completion date Original budgetversus actual cost of completing the project *> Test
plans and testresults
Outstanding Issues
Itemized list and expected completion
Any ongoing support required and duration
Project Documentation List
Systems Documentation
User Manuals
* Training Materials
Maintenance Documentation
The Final Meeting and Presentation
Mission MCA

207

Mission MCA

If the project manager has been diligent in gaining the confidence of the project sponsor,the
final meeting and presentation should be a simple, straightforward affair.Buttrick (2000)
suggests that the final meeting is useful for:
Communicating that the project is over. By inviting key stakeholders to themeeting, the
project manager is formally announcing that the project isover. This action not only provides
a sense of closure for those close to theproject, but also for the organization, as well.
Transferring the information system from the project team to the organization,Although
the information system may have been implemented and is beingused by the organization,
the final meeting provides a formal exchange of theproject's product from the project team
to the organization. Unless some typeof ongoing support is part of the contractual
agreement, this transfer signalsthat the project team will not be at the client or sponsor's
site much longer.
Acknowledging contributions. The meeting provides a forum for the projectmanager to
acknowledge the hard work and contributions of the projectteam and other key
stakeholders.
Getting formal signoff. Finally, the meeting can provide a ceremony for thesponsor or
client to formally accept the information system by signing offon the project. A space for
signatures could be part of the final projectreport or part of some other contractual
document.
Closing the Project
Once the project is accepted by the sponsor or customer, a number of administrativeclosure
processes remain. These last items can be difficult because the project manageror team
may view these administrative items as boring or because they are alreadylooking forward
to and thinking about their next assignment (Gray and Larson 2000).Unfortunately,
administrative closure is a necessity because once the project managerand team are
officially released from the current project, getting them to wrap up thelast of the details
will be difficult. The requirements for administrative closure include:
1. Verifying that all deliverables and open items are complete.
2. Verifying the project sponsor or customer's formal acceptance of the project.
3. Organizing and archiving all project deliverables and documentation.
4. Planning for the release of all project resources (i.e., project team members,
technology, equipment, facilities, etc.).
5. Planning for the evaluations and reviews of the project team members and
the project itself.
6. Closing of all project accounts.
7. Planning a celebration to mark the end of a (successful) project.

Mission MCA

208

Mission MCA

9.3 Project Evaluation

The question on everyone's mind throughout the project is, Will this project be
successful?However, different stakeholders will have different views of success. For
theproject team members, it may be gaining valuable experience and feeling that theirwork
will have a positive impact on the organization. For the project manager, it may beleading a
project that will be profitable to the firm or a promotion to a larger and morevisible project.
On the other hand, the client or sponsor may view project success interms of organizational
value received after the project is implemented.Therefore, four types of project evaluations
should be conducted. There shouldbe
(1) an individual review of each team member's performance,
(2) a postmortem review by the project manager and project team, (3) an audit of the
project by anobjective and respected outside party, and (4) an evaluation sometime after
the projectis implemented to determine whether the project achieved its envisioned MOV.
Individual Performance Review
The project manager should conduct an individual performance review with eachproject
team member. Although the project organization may have its own processand procedure
for conducting reviews, the project manager should focus on the followingpoints:
Begin with the individual evaluating his/her performance. Evaluatingsomeone's
performance can be an emotional experience. Even with the bestintentions, being critical of
someone can put her or him on the defensive.Instead of beginning an evaluation with a
critique of the individual's performance,it is usually more effective to begin by asking how
that personwould evaluate her or his performance. Surprisingly, most people are
morecritical of themselves. This opening provides an opportunity for the persondoing the
evaluation either to agree or to disagree with the individual'sself-evaluation and to point
out several positive aspects of the person'sperformance. This system creates a useful dialog
that provides the individualwith more useful feedback.
Postmortem Review
Avoid "why can'tyoube more like....?" It is easy to compare individuals.Unfortunately,
comparisons can have a counter effect. First, the personthat you exalt may not be the
shining star you think they are. Second, others may become jealous and look for ways to
discredit or disparage theindividual. Keep in mind that people are different and should be
evaluated as individuals.
Focus on specific behaviors, not the individual. When discussing opportunities for
improvement with a person, it is important to focus on specificbehaviors. For example, if a
project team member has a habit of consistently showing up late and disrupting team
meetings, it is important not tofocus on the individual (i.e., why are you so lazy and
disrespectful?), buton how showing up late to team meetings is disruptive. Often people do
notrealize how their behaviors affect others.

Mission MCA

209

Mission MCA

Be consistent and fair. Being consistent and fair to everyone is easier saidthan done. The
person conducting the evaluation should be aware of howdecisions concerning one person
may affect the entire group. Also, beaware that people talk to one another and often
compare notes. Therefore,making a decision concerning one person may set a precedent for
others.Having policies and procedures in place and sticking to them can mitigatethe
potential for inconsistency and the perception that that the evaluator isnot fair with
everyone.
Reviews should provide a consensus on improving performance. The purpose of conducting
a review or evaluation with each project team memberis to provide constructive feedback
for individuals. No one is perfect, sounderstanding where an individual can improve and
how they might goabout improving is important. The individual and the evaluator
shouldagree on what areas the individual needs to improve upon and how theorganization
can support this endeavor.
For example, the individual and theevaluator may agree that the team member should
improve his or her communication skills. The evaluator may then recommend and provide
supportfor the person to attend a particular training class.The meeting can serve to help
prepare the individual to move on and accept thepsychological fact that the project will end
(Gray and Larson 2000). And, in mostcases, the project manager could use this meeting to
discuss the project team member'snext assignment.Shortly after the final project report and
presentation are completed, the project managerand project team should conduct a
postmortem review of the project. This shouldbe done before the project team is released
from the current project. It is more difficultto get people to participate once they are busy
working on other projects or if they nolonger work for the project organization. Moreover,
memories tend to become cloudedas time passes. Thoroughness and clarity are critical
(Nicholas 1990). The forma project summary report should focus on the project's MOV and
the projectmanagement knowledge areas. The focus of this review should include the
following:
Review the initial project's MOV. Was the project's MOV clearly defined andagreed upon?
Did it change over the course of the project? What is theprobability that it will be achieved?
Review the project scope, schedule, budget, and quality objectives. Howwell was the scope
defined? Did it change? How effective were the scopemanagement processes? How close
were the project schedule and budgetestimates to the actual deadline and cost of the
project? Were the qualityobjectives met? How well did the quality management processes
and standards support the project processes?
Review each of the project deliverables. How effective were the businesscase, the project
charter, the project plan, and so forth? How could thesedeliverables be improved?
Review the various project plans and Project Management Body ofKnowledge (PMBOK)
areas. The team should review its effectiveness inthe following areas:
project integration management
project scope management
Mission MCA

210

Mission MCA

project time management

project cost management
project quality management
project human resources management
project communications management
project risk management
project procurement management
organizational change management
project implementation
How well did the project team perform? Were conflicts handled effectively?Did the team
suffer any morale problems? What main challenges did theteam face? How well did they
handle these challenges? How well did themembers function as a cohesive team?The
discussion and recommendations from the postmortem review should bedocumented. In
particular, the project manager and team should identify what theydid right and what they
could have done better. These lessons learned should bedocumented so that they can be
shared with others in the organization. Moreover,best practices should be identified and
become part of the organization's IT projectmethodology.
Project Audit
The individual performance and postmortem reviews provide an important view ofthe
internal workings of the project. In general, these reviews are conductedbetween the
project manager and the project team. To provide a more objectiveview of the project, an
audit or review by an outside party may be beneficial foruncovering problems, issues, or
opportunities for improvement. Similar to thepostmortem review, the auditor or audit team
should focus on how well the projectwas managed and executed. This may include the
project plans and ProjectManagement Body of Knowledge areas described in the previous
section, as well asthe underlying project management and systems development processes
outlinedin the organization's IT project methodology. In addition, the auditor or auditteam
should assess whether the project manager and team acted in a professionaland ethical
manner.As Gray and Larson (2000) suggest, the depth of the audit depends on the
organization'ssize, the importance and size of the project, the risks involved, and
theproblems encountered. The audit may involve the project manager and the projectteam,
as well as the project sponsor and other key project stakeholders. In addition,the third party
auditor or audit team should:
Have no direct involvement or interest in project.
Be respected and viewed as impartial and fair.
Be willing to listen.
Present no fear of recrimination from special interests.
Act in the organization's best interest.
Have broad base of project and/or industry experience.

The findings or results of the project audit should be documented, as well as anylessons
learned and best practices.Evaluating Project SuccessThe MOVThe MOV, or measurable
Mission MCA

211

Mission MCA

organization value, was defined at the beginning of the project.It provided the basis for
taking on the project and supported many of the decisionpoints throughout the project life
cycle. Often, the MOV cannot be readily determinedat the close of the project. Many of the
benefits envisioned by the implemented systemmay require weeks or even months before
they are realized.Although the different project stakeholders and players may have different
viewsas to whether the project was a success, it is important to assess the value that the
projectprovides the organization. This review may be conducted by several people from
boththe project sponsor or client's organization and the organization or area responsible
forcarrying out the project. In particular, this review should focus on answering
anddocumenting the following questions:
Did the project achieve its MOV?
Was the sponsor/customer satisfied?
Was the project managed well?
Did the project manager and team act in a professional and ethical manner?
What was done right?
What can be done better next time?
Before conducting this evaluation, the consulting firm or individuals representingthe project
should be sure that the information system delivered has not been changed.Often when an
information system is handed over to the project sponsor, the users orsupport staff may
make changes. It is not uncommon for these changes to have unintendedadverse affects.
Care should be taken to ensure that the system being evaluatedis the system that was
delivered (Nicholas 1990).The evaluation of the project's MOV may be intimidatingit can
be the momentof truth as to whether the project was really a success. However, a
successful IT projectthat brings measurable value to an organization provides a foundation
for organizationalsuccess.

9.4 Leadership & Ethics in Projects

9.4.1Project Leadership
James Kouzes and Barry Posner (2002) conducted research for over 20 years on effective
leadership experiences. Based on this research, they defined Five Practices of Exemplary
Leadership that can help you have a clearer direction to become a more effective successful
project leader.
1. Model the Way: The most effective leaders lead by example. A leader's behavior wins
respect, not his or her title or position within the organization. You must find with your own
voice based on your personal values and beliefs, but what you do in terms of your behaviors
and daily actions is often more important than what you say. Your words and deeds must be
consistent so that you convey the right message. Leaders set an example of what they
expect from others by modeling the way they want others to behave. This provides the
leader with the respect and the right to lead others. people follow the person first, not the
plan.

Mission MCA

212

Mission MCA

2. Inspire a Shared Vision: An exemplary leaders has an exciting vision or dream that acts
as a force for inventing the future. In turn, this vision should inspire people so they become
committed to a purpose. This requires the leader to know their constituents so that they will
believe the leader to understands their needs, interests, and "Speaks their Language." A
leader must engage in dialogue, not monologue, to understand the hopes and dreams of
others and gain their support. A leader should try to ignite the passion in others through
communication and enthusiasm of what the future could be.
3. Challenge the Process: Exemplary leaders do not rely on fate or luck. They venture out
and accept challenges. Leaders are pioneers who challenge the status quo by seeking out
new opportunities to innovate, grow, and improve. However, most leaders do not create,
developed, or come up with new products, services, or processes. Often leaders are good
listeners who recognize good ideas, support those ideas, and then challenge the process to
but innovation and change require experimentation, risks, and failure.
4. Enable Others to Act: Visions and dreams do not just happen because of one person's
actions. This requires a team effort so a leader's ability to get others to act is crucial.
Exemplary leaders enables other to act by encouraging collaboration and building trust
among all the project stakeholders.Leaders provide an environment that makes it possible
for others to do good work. People should feel empowered and motivated to do their best,
feel a sense of ownership, and take pride in what they do.
5 Encourage The Heart; Often the project journey is long and difficult. People can become
tired, disillusioned, frustrated, and willing to give up,Exemplary leaders rally others to carry
on by encouraging the heart. Although this encouragement can be a simple gesture such as
a thank-you note or something more dramatic like a matching band, the leader should show
appreciations for people's contributions and create a culture of celebration that recognizes
those accomplishments.

Leadership Styles
Following summary of the six styles will help you understand how a particular leadership
style influences performance and results.
1. The Coercive Style: The coercive style can be summarized as a "do as I say" approach to
leading others. This style can be effective in a crisis, to kick-start a turnaround situation,
when dealing with a problem employee, or when the leader is attempting to achieve
immediate compliance.
For Example, an extreme top-down approach to decision-making and communication can
often obstruct new ideas if people believe their ideas will be shot down or limit
communication if people are apprehensive of being the bearer of bad news.
2. The Authoritative Style: The leader who follows the authoritative style takes a "come
with me" approach in which the leader outlines a clearly defined goal but empowers people
to choose their own means for achieving it. The Authoritative leader provides vision and
Mission MCA

213

Mission MCA

enthusiasm. He or she motivates people by making it clear as to how their work fits into the
larger picture. people know that what they are doing has meaning and purpose.
3. The Affiliative Style: This style follows the attitude that "people come first." The
Affiliative style centers on the value of the individual rather than goals and tasks and
attempts to keep people happy by creating harmony among them. The leader who uses this
style attempts to build strong emotional bonds that translate into strong loyalty. The
affiliative style works well in situations that require building team harmony, morale, trust, or
communication.
4. The Democratic Style: The democratic style attempts to develop consensus through
participation by asking, "What do you think?" Using this style, the leader spends time
getting other people's ideas, while building trust, respect, and commitment. The democratic
style works best when the leader needs to build buy-in or consensus or to gain valuable
input from others. The democratic style would not be appropriate in a crisis or when the
team does not have competence or experience to offer sound advice.
5. The Pacesetting Style: A leader who uses the pacesetting style sets high performance
standards and has a "do as I do, now" attitude. This style exemplifies an obsession with
doing things better and faster for him or herself and everyone else. Poor performers are
quickly identified and replaced if standards are not met. The pacesetter sets the pace for
everyone else so that the work is completed on time or ahead of schedule.
6. The Coaching Style: The coaching style leader follows the "try this" approach to help
people identify their unique strengths and weaknesses so that they can reach their personal
and career goals. The leader who uses the coaching style encourages people to set longterm professional goals and then helps them develop a plan for achieving them.

9.4.2Ethics in Projects
Over the last several years, a great deal of attention has been given to organizations that
have had ethical meltdowns. The questionable business dealings of Enron executives, for
example, led to the largest corporate bankruptcy in U.S. history. This sinking ship also led to
the demise of Arthur Andersen, LLP, which at one time was one of the Big Five international
accounting firms. Although these are just two examples, the list of questionable ethical
behaviours by organizational leaders is long and distinguished. Unfortunately, this list is
getting longer.
As a result, many organizations are mandating and investing in ethical training for their
employees. Over the last few years, many business programs in colleges and universities
have added ethics courses or ethical components to courses to give students a sounder
ethical foundation. From a philosophical view, ethics can be defined as a set of moral
principles and values. Ethical dilemmas arise when our personal values come into conflict.
However, Trevino and Nelson (2004) take a more practical view that can help you
understand and apply several principles of ethics in a project setting: But our definition of
ethicsthe principles, norms, and standards of conduct governing an individual or group
focuses on conduct. We expect employers to establish guidelines for work-related conduct,
Mission MCA

214

Mission MCA

including what time to arrive and leave the workplace, whether smoking is allowed on the
premises, how customers are to be treated, and how quickly work should be done.
Guidelines about ethical con-duct aren't much different. Many employers spend a lot of
time and money developing policies for a range of employee activities, from how to fill out
expense reports to what kind of client gifts are accept-able. to what constitutes a conflict of
interest or bribe. If we use this definition, ethics becomes an extension of good
management. Leaders identify appropriate and inappropriate conduct, and they
communicate their expectations to employees through ethics codes, training programs, and
other communication channels (13). You may be wondering whether this reaction is worth
the time and effort. The answer is that unethical business behaviours cost organizations
money and jobs. For example, at the end of 20(X).
Enron's stock was trading at over $80 a share. Less than a year later, it fell to less than a
dollar a share. The dreams of many innocent investors went up in smoke. Even more
disconcerting is the fact that over 20,000 employees lost their jobs. In addition, acting
unethically can also mean breaking a law. This can lead to not only financial penalties, but
jail time as well. Moreover, acting ethically is just the right thing to do. It's not only in your
best interest; it's in the best interest for people who are part of organizations and society.
People want to work for and do business with organizations they can trust. Credibility and
reputation take a great deal of effort and time to build, but can be ruined almost in an
instant.
trust if special favours are extended only to special friends at the expense of others. Many
organizations have policies that define situations that are and are not acceptable. Conflict of
interest issues can include such things as overt or subtle bribes or kickbacks as well as
relationships that could question your impartiality. Moreover,.as a project team member,
you will gain access to confidential and private information that could be of value to you or
someone else. When in doubt, it's best to provide full disclosure to mitigate any risk of
impropriety.
ConfidenceA project includes a number of stakeholders. Meeting or exceeding project
stakeholder expectations, especially the client's, requires maintaining a strong sense of
confidence with respect to such issues as confidentiality, product safety or reliability, truth
in advertising, and special fiduciary responsibilities that require special commitments or
obligations to the client or other project stakeholders. Although confidence issues can
include a wide variety of issues, they can create special ethical considerations that can affect
your relationship with project stakeholders. Trust can erode when your fairness, honesty, or
respect come into question.
Corporate ResourcesAs a project team member, you are a representation of both your
team and your organization. This means that you are considered an agent of your
organization and your actions can be considered the actions of your organization. For
example, if you are a consultant working with a client, people will infer that you are
representing and speaking on behalf of your company. In turn, your company may give you
an e-mail address with their domain, business cards, and stationery with the corporate
letterhead. Therefore, your e-mail and organizational stationery should only be used for
Mission MCA

215

Mission MCA

business purposes. For example, writing a letter of recommendation for someone means
that both you and your organization share the same opinion. Make sure that your personal
opinion and corporate opinions are not in conflict. In addition, company equipment and
services should only be used for business purposes. Often companies have policies about
personal phone calls and e-mail or the acceptable use of equipment. Another important
issue concerns the truth. Many times people are asked to "fudge" the numbers by making
things appear better than what they are. Although many organizations now have
procedures to follow if you're asked to engage in this type of behaviour, you may want to
consult with someone outside the chain of command such as someone in the legal
department or human resources department if this type of situation arises and no policy
exists. However, becoming a "whistle blower" can have its consequencesintended and
unintendedand should be an option used with caution and as a last resort.
An article called Business Ethics: A View from the Trenches by Joseph Badaracco, Jr. and
Allen Webb (1995) summarizes a study of in-depth interviews with thirty Harvard MBA
graduates and describes a number of interesting patterns. For example, many of the young
managers received explicit instructions from their boss or felt strong pressure to do things
that they considered were sleazy, unethical, or sometimes illegal. Moreover, many of the
recent graduates attempted to resolve their ethical dilemmas through personal reflection
and individual values, rather than reliance on corporate statements, organizational loyalty,
the exhortations of senior executives, or religious and philosophical principles. into still
waters. The impact of your actions can be immediate and felt over time.
5. Identify the ObligationsAfter you have identified the consequences of your action or
decision, the next step involves identifying the obligations you have to the affected
stakeholders. It may help to think of obligations in terms of values, principles, character, and
outcomes. For example, you may feel loyalty toward your supervisor because he or she
hired you at a time when you were financially desperate or because you want to be viewed
as a team player. On the other hand.you have an obligation to the client to tell the truth and
report the results as they are.
6. Consider Your Character and IntegrityMany people find the "sleep test" as a proxy for
how the world would view their actions. Will your action or decision allow you to sleep
restfully at night? Another way is to ask yourself. Would you feel comfortable if your action
or decision were to appear on the news? Moreover, what would someone close to you (and
whose opinion really matters) say if you told that person about your action or decision? In
short, do you want people to say that you were a person of integrity or not?
7. Think Creatively about Potential ActionsIn coming up with a potential solution to an
ethical dilemma, it is important that you do not "force your-self into a corner" by framing
your decision in terms of two choices. In our example, this may mean either changing the
test results as the supervisor wants or bypassing his or her authority and telling your boss's
boss what your supervisor asked you to do. There may be a policy in your organization that
outlines steps you could follow for blowing the whistle on your supervisor, but another
option may be to talk with your supervisor and explain that you are uncomfortable with
changing the results. Explaining the impact and consequences of the action may be enough
to change the supervisor's mind. If that doesn't work, other options might include making
Mission MCA

216

Mission MCA

sure that someone else knows what the original (and correct) test results report. Each
situation is unique and therefore requires a unique and some-times creative approach.
Talking to someone outside the situation can be a great help.
8. Check Your GutAlthough the previous steps tend to follow a rational approach. you still
need to check your gut or intuition. Empathy should not be discarded over logic because it
can raise a warning flag that someone might be harmed. If your intuition is troubling you,
then it may be time for more thought on the issue or situation. However, making a decision
based solely on emotion is probably not a good idea either. Checking your gut should be a
final stage of the process that provides you with confidence in your action or decision.

9.4.3 Multicultural Projects

A common type of multicultural project would be an international one. However, domestic
projects are becoming increasingly multicultural as many organizations attempt to diversify
their workforce. Although ethics is an important component of leadership, the ability to lead
and manage a multicultural team will become an increasingly more important skill for
successful project leaders.
The Challenges of International Projects
The thought of being part of an international project can be excitingtravel, hotels, exotic
food, and different customs. However, international projects also entail new challenges that
can make or break your career depending on how well you handle these new and strange
situations. International projects are more complex because geographical, cultural, and
social differences must be taken into account (Lientz and Rea 2003). These complexities
include:
Number of LocationsOften international projects are located in several dif-ferent
countries, cities, or regions. Travel time and costs must be taken into account as well as
differences in time zones.
Currency ExchangeMost countries today still have their own unique currency. These
currencies are subject to fluctuations in exchange rates and inflation. Moreover, some
currencies are not valued outside the issuing country.
Regulations and LAWSEach country has its own regulations and laws, but laws can be
local and interpreted differently.
Political InstabilityDoing a project in a politically unstable country can create interesting
challenges that can endanger the safety and welfare of the project team.
Attitude Toward Work and TimeDifferent cultures can have different attitudes toward
work and time. For example.in some cultures work is perceived as something not that
critical. People do what they have to do, and getting ahead is not important. On the other
hand, work for some becomes an obsession and their job and title define who they are. For
Mission MCA

217

Mission MCA

these individuals, competition to be the best is important because it can lead to promotion
and more pay. In addition, people in some cultures feel less pressure to be regulated by a
clock and may not even own one. As a result, a project leader who attempts to make people
work harder or adhere to time pressure will meet resistance.
ReligionAlthough religion has an important influence in all societies, some societies are
more affected in terms of how they go about their daily life and their work. For example.in
many Islamic countries the weekend is on Thursday and Friday. while in other countries the
weekend is on Saturday and Sunday. In such cases, offices in two different countries may be
able to communicate only on Mondays: Tuesdays, and Wednesdays (Murphy 2005).
LanguageNot everyone speaks the same language you do. Although English has become
the international language of business, not everyone can speak it fluently and words can
have different meanings. Careful selection of words and phrases is important to reduce the
likelihood that they are misunderstood or misinterpreted.
Food some people have different tests and are more willing to try new things. Each
country has its own cuisine that may seem strange, but dont forget that what seems normal
to you can b strange or even disgusting to someone from somewhere else.

Mission MCA

218