SyllabusM.C.A. (Sem-IV), Paper-V

Software Project Management

1. Introductiona. What is project?b. What is project Managementc. The role of project Managerd. The project Management Professione. Project life cycle

2. Technology Contexta. A system view of project managementb. Understanding organizationsc. Stakeholder managementd. Project phases and the project life cyclee. The context of information technology projects

3. Introductiona. Developing the project scheduleb. Project management software toolsc. Developing the project budgetd. Finalizing the project schedule and budgete. Monitoring and controlling the projectf. The project communications plang. Project metricsh. Reporting performance and progressi. Information distribution

4. The importance of project risk managementa. Risk management planningb. Common sources of risk on information technology projectsc. Risk identificationd. Qualitative risk analysise. Quantitative risk analysisf. Risk response planningg. Risk monitoring and controlh. Using software to assist in project risk management

5. The importance of project procurement managementa. Planning purchase and acquisitionsb. Planning contractingc. Requesting seller responsesd. Selecting sellerse. Administering the contractf. Closing the contractg. Using software to assist in project managementh. Outsourcing

6. Change management

2

a. The nature of changeb. The change management planc. Dealing with resistance and conflict

7. Leadership & Ethics in Projectsa. Project leadershipb. Ethics in projectsc. Multicultural projects

8. Introductiona. Project implementationb. Administrative closurec. Project evaluation

References:1. Information Technology Project Management: Kathy

Schwalbe Thomson Publication.2. Information Technology Project Management providing

measurable organizational value Jack Marchewka WileyIndia.

3. Applied software project management Stellman & GreeneSPD.

4. Software Engineering Project Management by RichardThayer, Edward Yourdon WILEY INDIA.

3

1

INTRODUCTION

Unit Structure:

1.1 What is a project?

1.1.1 Project Definition

1.2 Project Attributes

1.3 Project Constraints

1.3.1 Time

1.3.2 Cost

1.3.3 Scope

1.4 What is Project Management

1.4.1 Features of projects

1.4.2 Project Classification

1.4.3 Project Management Tools and techniques

1.4.4 Project Success Factors

1.5 The Role of Project Manager

1.5.1 Responsibilities of a Project Manager.

1.6 Project Life Cycle

1.6.1 Project Initiation

1.6.2 Planning & Design

1.6.3 Execution & Controlling

1.6.4 Closure

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 1950sthat 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 defenseactivity. 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 form the foundation of the body of

4

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 A 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 project’s 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 it’sthere 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 a sense of

5

being 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 PROJECT ATTRIBUTES

Projects come in all shapes and sizes. The followingattributes help us to define a project further:

- A project has a unique purpose. Every project should have awell-defined objective. For example, many people hire firmsto design and build a new house, but each house, like eachperson, is unique.

- A project is temporary. A project has a definite beginningand a definite end. For a home construction project, ownersusually have a date in mind when they’d like to move intotheir new homes.

- A project is developed using progressive elaboration or in aniterative fashion.

Projects are often defined broadly when they begin, and astime passes, the specific details of the project becomeclearer. For example, there are many decisions that must bemade in planning and building a new house. It works best todraft preliminary plans for owners to approve before moredetailed plans are developed.

- A project requires resources, often from various areas.Resources include people, hardware, software, or otherassets. Many different types of people, skill sets, andresources are needed to build a home.

- A project should have a primary customer or sponsor. Mostprojects have many interested parties or stakeholders, butsomeone must take the primary role of sponsorship. Theproject sponsor usually provides the direction and fundingfor the project.

- A project involves uncertainty. Because every project isunique, it is sometimes difficult to define the project’sobjectives clearly, estimate exactly how long it will take tocomplete, or determine how much it will cost. Externalfactors also cause uncertainty, such as a supplier going outof business or a project team member needing unplannedtime off. This uncertainty is one of the main reasons projectmanagement is so challenging.

6

1.3 PROJECT CONSTRAINTS

Like any human undertaking, projects need to be performedand delivered under certain constraints. Traditionally, theseconstraints have been listed as scope, time, and cost. These arealso referred to as the Project Management Triangle, where eachside represents a constraint. One side of the triangle cannot bechanged without impacting the others. A further refinement of theconstraints separates product 'quality' or 'performance' from scope,and turns quality into a fourth constraint.

The time constraint refers to the amount of time available tocomplete a project. The cost constraint refers to the budgetedamount available for the project. The scope constraint refers towhat must be done to produce the project's end result. These threeconstraints are often competing constraints: increased scopetypically means increased time and increased cost, a tight timeconstraint could mean increased costs and reduced scope, and atight budget could mean increased time and reduced scope.

The discipline of project management is about providing thetools and techniques that enable the project team (not just theproject manager) to organize their work to meet these constraints.

Another approach to project management is to consider thethree constraints as finance, time and human resources. If youneed to finish a job in a shorter time, you can allocate more peopleat the problem, which in turn will raise the cost of the project, unlessby doing this task quicker we will reduce costs elsewhere in theproject by an equal amount.

1.3.1 Time:

For analytical purposes, the time required to produce aproduct or service is estimated using several techniques. Onemethod is to identify tasks needed to produce the deliverablesdocumented in a work breakdown structure or WBS. The workeffort for each task is estimated and those estimates are rolled upinto the final deliverable estimate.

The tasks are also prioritized, dependencies between tasksare identified, and this information is documented in a projectschedule. The dependencies between the tasks can affect thelength of the overall project (dependency constraint), as can theavailability of resources (resource constraint). Time is notconsidered a cost nor a resource since the project manager cannot

7

control the rate at which it is expended. This makes it different fromall other resources and cost categories.

1.3.2 Cost:

Cost to develop a project depends on several variablesincluding : labor rates, material rates, risk management, plant(buildings, machines, etc.), equipment, and profit. When hiring anindependent consultant for a project, cost will typically bedetermined by the consultant's or firm's per diem rate multiplied byan estimated quantity for completion.

Figure 1.1 : The Project management Triangle

1.3.3 Scope:

Scope is requirement specified for the end result. The overalldefinition of what the project is supposed to accomplish, and aspecific description of what the end result should be or accomplishcan be said to be the scope of the project. A major component ofscope is the quality of the final product. The amount of time put intoindividual tasks determines the overall quality of the project. Sometasks may require a given amount of time to complete adequately,but given more time could be completed exceptionally. Over thecourse of a large project, quality can have a significant impact ontime and cost or vice versa.

Together, these three constraints viz. Scope, Schedule &Resources have given rise to the phrase "On Time, On Spec, OnBudget". In this case, the term "scope" is substituted with"spec(ification)"

8

1.4 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 pre-emptive and 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.4.1 Features of projects:

9

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.

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.4.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 constructionThe 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 systemsThese 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 changeAn 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.

10

1.4.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 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 time-management tools 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 Tools & Techniques

Integrationmanagement

Project selection methods, projectmanagementmethodologies, stakeholder analyses,project charters, project managementplans, project management software,change requests, change control boards,project review meetings, lessons-learnedreports

Scope management Scope statements, work breakdownstructures,mind maps, statements of work,requirementsanalyses, scope management plans,scope verification techniques, and scopechange controls

Cost Management Net present value, return on investment,paybackanalyses, earned value management,project portfolio management, costestimates, cost management plans, costbaselines

Time management Gantt charts, project network diagrams,critical-path analyses, crashing, fasttracking, scheduleperformance measurements

Human resourcemanagement

Motivation techniques, empathic listening,responsibility assignment matrices,projectorganizational charts, resourcehistograms, teambuilding exercises

11

Quality management Quality metrics, checklists, quality controlcharts,Pareto diagrams, fishbone diagrams,maturity models, statistical methods

Risk management Risk management plans, risk registers,probability/impact matrices, risk rankings

Communicationmanagement

Communications management plans,kickoffmeetings, conflict management,communicationsmedia selection, status and progressreports, virtual communications,templates, project Web sites

Procurementmanagement

Make-or-buy analyses, contracts,requests forproposals or quotes, source selections,supplierevaluation matrices

Table 1.1 : Project Management Tools and Techniques

1.4.4 Project Success Factors:

The successful design, development, and implementation ofinformation technology (IT) projects is a very difficult and complexprocess. However, although developing IT projects can be difficult,the reality is that a relatively small number of factors control thesuccess or failure of every IT project, regardless of its size orcomplexity. The problem is not that the factors are unknown; it isthat they seldom form an integral part of the IT developmentprocess.

Some of the factors that influence projects and may help themsucceed are

- Executive Support- User involvement- Experienced project managers- Limited scope- Clear basic requirements- Formal methodology- Reliable estimates

1.5 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 maintainthe progress and productive mutual interaction of various parties insuch a way that overall risk of failure is reduced.

12

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

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

13

company 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.6 PROJECT LIFE CYCLE

The Project Life Cycle refers to a logical sequence ofactivities to accomplish the project’s 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. Let’s take a closer lookat what’s important in each one of these stages:

1.6.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 business’s 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.

14

Conceptual design of the operation of the final product.

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.

Figure 1.5 : Project Life Cycle

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

15

- Can be produced within acceptable quality standards.

- Can be produced within time and budget constraints.

1.6.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);

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 implemented

In 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 the

16

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

Sample Questions

1. Why is there a new or renewed interest in the field of projectmanagement?

2. What is a project, and what are its main attributes? How is aproject different from what most people do in their day-to-dayjobs? What is the triple constraint?

3. What is project management? Briefly describe the projectmanagement framework, providing examples of stakeholders,knowledge areas, tools and techniques, and project successfactors.

4. Discuss the relationship between project, program, and portfolioManagement and their contribution to enterprise success.

5. What are the roles of the project, program, and portfoliomanagers? What are suggested skills for project managers?What additional skills do program and portfolio managers need?

17

2

TECHNOLOGY CONTEXT

Unit Structure:

2.1 A systems view of project management.

2.1.1 The Three Sphere model for Systems management

2.1.2 A Case

2.2 Understanding Organisations

2.2.1 The key roles

2.2.1.1 Top management

2.2.1.2 The Project Board

2.2.1.3 Project Manager

2.3 Stakeholder Management

2.3.1 Stakeholder Agreements

2.4 The Context of Information Technology Projects

2.4.1. Software Projects

2.4.2 Software Development Process

2.4.3 Requirements Engineering

2.1 A SYSTEMS VIEW OF PROJECT MANAGEMENT

There are many aspects of project management that areimportant and worthy of comment. There are so many details thatmust be handled in order for a project to be successful. To be ableto handle the day to day details while still keeping your eye of thestrategic whole is a demanding task but one that can be learnedand improved.

As the project is a temporary, one-time endeavor undertakento solve a problem or take advantage of an opportunity, It usuallyhas a customer or customers (either internal or external to the

18

organization that are doing the project), a budget or a set of scarceresources that must be managed and some kind oftimeframe/constraint for completion or operation. Before one canundertake a project to solve a problem one must first understandthe problem. Not only understand the details of the problem butalso understand who has the problem and the context andenvironment that must be taken into consideration in addressingthe problem.

A key practice in getting things clear is to look at the problemfrom the customers and users perspectives.

- What is important to the customer?

- How will the user actually be using the system.

- What does the world look like from their perspective?

- What do they value and what is the solution worth?

- Engineers tend to focus on features while customers areinterested in benefits; how will this help them solve theirproblems.

One way to get this perspective is to spend time with thecustomers and users and enter into a dialog with them. If projectmanagers run projects in isolation, these projects will never servethe needs of the organisation for which it is undertaken. Projectmanagers thus should consider projects within the greaterorganizational context and take a holistic view of a project. Systemsthinking describes this holistic view of carrying out projects.

A systems approach is an overall model for thinking aboutthings as systems. Systems are sets of interacting componentsworking within an environment to fulfill some purpose. Systemanalysis is a problem-solving approach that requires defining thescope of the system, dividing it into its components, and thenidentifying and evaluating its problems, its opportunities constraintsand needs. Once this is completed, the systems analyst thenexamines alternative solutions for improving the current situation,identifies an optimum, or at least satisfactory, solution or actionplan, and examines that plan against the entire system. Systemsmanagement addresses the business, technological, andorganizational issues associated with creating, maintaining, andmaking a change to a system.

Using a systems approach is critical to successful projectmanagement. Top management and project managers must follow

19

a systems philosophy to understand how projects relate to thewhole organisation.

2.1.1 The Three Sphere model for Systems management:

The three-sphere model of systems management deals withthe business, organizational and technological aspects and/orissues related to the project that should be defined and consideredin order to select and manage projects effectively and successfully.In terms of addressing its advantage on the business side, a projectshould supplement or serve as an answer to the business goals;whereas, the technological sphere should state the properhardware and software issues to be resolved. As for theorganizational aspect, matters involving the stakeholders should betaken into full consideration. If the project manager would be able topoint out as early as possible the aforementioned issues andintegrate it to the project it would definitely aid in determining if anorganization should invest and produce the project.

Figure 2.1 : Three Sphere model for systems management

20

2.1.2 A Case:

A programmer was given a task to convert a static website ofa magazine into a dynamic PHP website; what prompts themanagement to engage into this project is the fact that the web hasbecome more sophisticated and that there has been a major shift of“print” audience to the internet. You’ll find below the business,organizational and technological issues of the said project.

Business issues:

1. Would the website be the medium in response to the impactof the internet in a publishing company?

2. Would the website supplement the magazine in terms ofadvertising?

3. What will the project cost the company?

4. What would be the impact of the website to the sales of themagazine?

5. What would be the cost of maintaining the whole system forthe website?

Technological issues:

1. What operating system, server platform, scripting languageand database should be used?

2. What will be the server and desktop specifications?

3. Does our current network setup allow employees to developthis project, or do we need an upgrade?

4. Do we have the right internet connection to support thisproject?

Organizational issues:

1. Do we have the existing manpower to develop the project?

2. What would be the impact of the website to the magazine’sprint division?

3. How will the website affect our print audience?

The most important issues are from the business andorganization spheres, since these two primarily follows thebusiness philosophy – it would definitely be pointless if a projectfails to meet the endeavors either on the business or organizational

21

side – it’s doomed to fail if that is the case. Among the three, Iguess the technological issues are the easiest to resolve.

2.2 UNDERSTANDING ORGANISATIONS

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

Figure 2.2 Organizational Structure

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 with

Top Management

Project Board &other functionaries

Project manager

Project team

22

exception situations outside authority of the project’s SeniorResponsible Owner.

There is not a ‘one-size fits all’ model for the projectorganisation; you must design it to suit such things as a project’s:

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.

2.2.1 The key roles:

2.2.1.1 Top management: (in certain circumstances/environmentsknown as Project Sponsor(PS) or Programme Director).

The management is the project’s 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 Manager

ensure that all key stakeholders are committed to the projectand adequately represented in the project’s organisationstructure

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

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

23

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 Manager

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

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

24

2.2.1.3 Project Manager:

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 project’s 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.

2.3 STAKEHOLDER MANAGEMENT

The importance of stakeholder management is to support anorganization in achieving its strategic objectives by interpreting andinfluencing 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 - Interested parties eitherinternal or external to organisation/project.

25

Stakeholder Analysis - Recognise and acknowledgestakeholder's needs, concerns, wants, authority, commonrelationships, interfaces and align this information within theStakeholder 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.

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

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

2.4 THE CONTEXT OF INFORMATION TECHNOLOGYPROJECTS

2.4.1. Software Projects:

Software development is a complex process involving suchactivities as domain analysis, requirements specification,communication with the customers and end-users, designing andproducing different artifacts, adopting new paradigms andtechnologies, evaluating and testing software products, installingand maintaining the application at the end-user's site, providingcustomer support, organizing end-user's training, envisioning

26

potential upgrades and negotiating about them with the customers,and many more.

In order to keep everything under control, eliminate delays,always stay within the budget, and prevent project runaways, i.e.situations in which cost and time exceed what was planned,software project managers must exercise control and guidanceover the development team throughout the project's lifecycle. Indoing so, they apply a number of tools of both economic andmanagerial nature. The first category of tools includes budgeting,periodic budget monitoring, user chargeback mechanism,continuous cost/benefit analysis, and budget deviation analysis.The managerial toolbox includes both long-range and short-termplanning, schedule monitoring, feasibility analysis, software qualityassurance, organizing project steering committees, and the like.

All of these activities and tools help manage a number ofimportant issues in the process of software development. Figure1.1 illustrates some of the issues, but definitely not all of them.

2.4.2 Software Development Process:

One of the primary duties of the manager of a softwaredevelopment project is to ensure that all of the project activitiesfollow a certain predefined process, i.e. that the activities areorganized as a series of actions conducing to a desirable end . Theactivities are usually organized in distinct phases, and the processspecifies what artifacts should be developed and delivered in eachphase. For a software development team, conforming to a certainprocess means complying with an appropriate order of actions oroperations. For the project manager, the process provides meansfor control and guidance of the individual team members and theteam as a whole, as it offers criteria for tracing and evaluation ofthe project's deliverables and activities.

27

Figure 2.3: Certain important issues in Software ProjectManagement

Software development process encompasses many differenttasks, such as domain analysis and development planning,requirements specification, software design, implementation andtesting, as well as software maintenance. Hence it is no surprise atall that a number of software development processes exist.

Generally, processes vary with the project’s goals (such astime to market, minimum cost, higher quality and customersatisfaction), available resources (e.g., the company’s size, thenumber, knowledge, and experience of people -- both engineersand support personnel -- and hardware resources), and applicationdomain.

However, every software developer and manager shouldnote that processes are very important. It is absolutely necessary tofollow a certain predefined process in software development. Ithelps developers understand, evaluate, control, learn,communicate, improve, predict, and certify their work. Sinceprocesses vary with the project's size, goals, and resources, as wellas the level at which they are applied (e.g., the organization level,the team level, or the individual level), it is always important todefine, measure, analyze, assess, compare, document, andchange different processes.

There are several well-known examples of softwaredevelopment processes. Each process relies on a certain model ofsoftware development. The first well established and well-documented software development process has followed thewaterfall model. One of its variants is shown in Figure 1.2. Themodel assumes that the process of software development proceedsthrough several phases in a more-or-less linear manner. Thephases indicated in Figure 1.2 are supposed to be relativelyindependent.

28

Figure 2.4 : Waterfall Model for Software DevelopmentThere is not much feedback and returning to previous

phases other than the one directly preceding the phase in focus. Inother words, once a certain phase is finished it is consideredclosed, and the work proceeds with the next phase. Manydevelopers have criticized the waterfall model for its rigidity in thatsense, and for its failure to comply with the reality of everchangingrequirements and technology. However, the waterfall model is atleast partially present in most of the other models as well, simplybecause of its natural order of phases in software development.

There have been many attempts to overcome the limitationsof the waterfall model. Two common points in all such attempts areintroduction of iterations in software development activities andincremental development. Iterative and incremental softwaredevelopment means going through the same activities more thanonce, throughout the product's lifecycle, each time producing newdeliverables and/or improving the old ones. The main advantage ofworking in that way is that each individual developer works on asmall ``work packet" at any given moment, which is much easier tocontrol.

A classical example of iterative and incremental models isthe spiral model , sketched in Figure 1.3. In the spiral model, thereare five core tasks: planning and design (largely corresponding tothe classical analysis phase), approval (requirements specification),realization (design and implementation), revision (testing andmodification), and evaluation (integration and system-level testing).The process iterates through these tasks, getting closer and closerto the end by adding increments (e.g., new functions, new design,new modules, new or improved testing procedures, new orimproved parts of the user interface, new integration and testingcertificates, and so on) to the product in each iteration.

29

Figure 2.5 : Spiral Model for Software DevelopmentThe spiral model underlies many processes, such as DBWA

(Design By Walking Around), and PADRE (Plan-Approve-Do-Review-Evaluate). The DBWA process combines the spiral modelwith multiple design views, flexible structuring of developmentteams, and dynamic changes in modes of working (e.g., workingindividually, working in pairs, or working in small teams), in order toimprove the process efficiency and parallelism. The PADREprocess uses the spiral model at multiple levels - the project level,the phase level, and the individual software module level - thuscreating the ``spiral in a spiral in a spiral" effect.

2.4.3 Requirements Engineering:

Requirements engineering is the discipline of gathering,analyzing, and formally specifying the user's needs, in order to usethem as analysis components when developing a software system .Requirements must be oriented towards the user's real needs, nottowards the development team and the project managers.

Almost all software development processes one way oranother stress requirements analysis and specification as one oftheir core workflows. The reasons are simple. It is necessary tomanage requirements as well as possible because a small changeto requirements can profoundly affect the project's cost andschedule, since their definition underlies all design andimplementation . Unfortunately, in most practical projects it is notpossible to freeze the requirements at the beginning of the projectand not to change them. Requirements develop over time, and theirdevelopment is a learning process, rather than a gathering one.The intended result of this process is a structured but evolving setof agreed, well understood, and carefully documented requirements. This implies the need for requirements traceability, i.e. the abilityto describe and follow the life of a requirement, in both a forwardand backward direction, ideally through the whole system's lifecycle.

The importance of constantly involving the users in theprocess of requirements analysis and specifications cannot beoveremphasized. Only the users know their domain properly, andfor that reason they should certainly participate in defining thesystem's functions, designing them, and evaluating theirimplementation and testing. The users should also participate increating, verifying, and updating the requirements specification

30

document for the project. The users should share with thedevelopers the responsibility for the requirements' completenessand consistency. It is the project managers' duty to establish andmaintain good relations with the users throughout the developmentprocess, as well as to consult them whenever the project gets stuckdue to the development team's lack of domain understanding.

It is essential to make as explicit as possible all therequirements that reflect the user's work and the tasks that thesoftware system under development is supposed to automate. Anysituation in which users can find themselves when doing their job isthe context that must be taken into account through requirementsengineering. It is equally important not to concentrate on a singleuser's task, but to cover communication between users when thetask requires collaboration.

There is a wide spectrum of techniques for requirementsengineering. Whatever technique is applied, it is always desirableto involve the user to increase the correctness of the requirementsspecification. Some of the techniques are:

Structured interviews and questionnaires that the user fills in(inquiry based requirements gathering); diagram-basedrequirements analysis (using multiple diagrams to sketchrelevant parts of the user's.

Work process and describe the requirements graphically).

Using metaphors of the user's work process (e.g., the officemetaphor, or the agent/agency metaphor);

Scenario analysis (scenario is a typical sequence ofactivities characterizing the user's work process, hence itreflects what the user will do with the system and helpsdefine the test procedures).

Using special-purpose software tools for requirementsgathering (some of them can be simulation-based)

Requirements completeness and consistency checks (someof them can be automated, others must be performedmanually).

Using special-purpose requirements-specification languagesin order to describe requirements more formally and henceprovide more automated requirements tracing.

Prototype system development, in order to make therequirements clear and to establish better mutualunderstanding with the users.

31

3

PROJECT SCHEDULING

Unit Structure:

3.1 Developing the Project Schedule

1.1 3.1.1. Schedule Inputs

1.2 3.1.2. Scheduling Tools

3.2 Project Management Software Tools

1.3 3.2.1. Allocate Resources to the Tasks

1.4 3.2.2. Identify Dependencies

1.5 3.2.3 Create the Schedule

2 3.2.4 RISK PLAN

3.3 Developing the Project Budget.

3.3.1 Costing

3.3.2 Budgeting

3.4 Monitoring and Controlling the Project

3.4.1 Checkpoints

3.4.1.1 Checkpoint design

3.4.2 Handling significant deviations from plan

3.4.3 Monitoring System Performance

3.5. The Project Communication Plan

3.5.1 Two Types of Communications Plans for Your Project

3.5.2 Building Your Plan

3.6 Project Metrics

2.1.1 3.6.1 Reasons for Project Metrics

3.6.2 Key Project Metrics

3.6.3 Developing Project Metrics

3.7 Reporting Performance & Progress

32

3.7.1 Project Status Report

3.1 DEVELOPING THE PROJECT SCHEDULE

Can you imagine starting a long car trip to an unfamiliardestination without a map or navigation system? You're pretty sureyou have to make some turns here and there, but you have no ideawhen or where, or how long it will take to get there. You may arriveeventually, but you run the risk of getting lost, and feelingfrustrated, along the way.

Essentially, driving without any idea of how you're going toget there is the same as working on a project without a schedule.No matter the size or scope of your project, the schedule is a keypart of project management. The schedule tells you when eachactivity should be done, what has already been completed, and thesequence in which things need to be finished.

Luckily, drivers have fairly accurate tools they can use.Scheduling, on the other hand, is not an exact process. It's partestimation, part prediction, and part 'educated guessing.'

Because of the uncertainty involved, the schedule isreviewed regularly, and it is often revised while the project is inprogress. It continues to develop as the project moves forward,changes arise, risks come and go, and new risks are identified. Theschedule essentially transforms the project from a vision to a time-based plan.

Schedules also help you do the following:

They provide a basis for you to monitor and control projectactivities.

They help you determine how best to allocate resources soyou can achieve the project goal.

They help you assess how time delays will impact theproject.

You can figure out where excess resources are available toallocate to other projects.

They provide a basis to help you track project progress.

Project managers have a variety of tools to develop a projectschedule - from the relatively simple process of action planning forsmall projects, to use of Gantt Charts and Network Analysis forlarge projects. Here, we outline the key tools you will need forschedule development.

33

2.2 3.1.1. Schedule Inputs:2.3

You need several types of inputs to create a project schedule:

Personal and project calendars - Understanding workingdays, shifts, and resource availability is critical to completinga project schedule.

Description of project scope - From this, you candetermine key start and end dates, major assumptionsbehind the plan, and key constraints and restrictions. Youcan also include stakeholder expectations, which will oftendetermine project milestones.

Project risks - You need to understand these to make surethere's enough extra time to deal with identified risks - andwith unidentified risks (risks are identified with thorough RiskAnalysis).

Lists of activities and resource requirements - Again, it'simportant to determine if there are other constraints toconsider when developing the schedule. Understanding theresource capabilities and experience you have available - aswell as company holidays and staff vacations - will affect theschedule.

A project manager should be aware of deadlines andresource availability issues that may make the schedule lessflexible.

2.4 3.1.2. Scheduling Tools:

Here are some tools and techniques for combining theseinputs to develop the schedule:

Schedule Network Analysis - This is a graphicrepresentation of the project's activities, the time it takes tocomplete them, and the sequence in which they must bedone. Project management software is typically used tocreate these analyses - Gantt charts and PERT Charts arecommon formats.

Critical Path Analysis - This is the process of looking at allof the activities that must be completed, and calculating the'best line' - or critical path - to take so that you'll complete theproject in the minimum amount of time. The methodcalculates the earliest and latest possible start and finishtimes for project activities, and it estimates the dependenciesamong them to create a schedule of critical activities anddates.

34

Schedule Compression - This tool helps shorten the totalduration of a project by decreasing the time allotted forcertain activities. It's done so that you can meet timeconstraints, and still keep the original scope of the project.You can use two methods here:

Crashing - This is where you assign more resources to anactivity, thus decreasing the time it takes to complete it. Thisis based on the assumption that the time you save will offsetthe added resource costs.

Fast-Tracking - This involves rearranging activities to allowmore parallel work. This means that things you wouldnormally do one after another are now done at the sametime. However, do bear in mind that this approach increasesthe risk that you'll miss things, or fail to address changes.

3.2 PROJECT MANAGEMENT SOFTWARE TOOLS

There are many project scheduling software products whichcan do much of the tedious work of calculating the scheduleautomatically, and plenty of books and tutorials dedicated toteaching people how to use them. However, before a projectmanager can use these tools, he should understand the conceptsbehind the work breakdown structure (WBS), dependencies,resource allocation, critical paths, Gantt charts and earned value.These are the real keys to planning a successful project.2.5 3.2.1. Allocate Resources to the Tasks:

The first step in building the project schedule is to identifythe resources required to perform each of the tasks required tocomplete the project. A resource is any person, item, tool, orservice that is needed by the project that is either scarce or haslimited availability.

Many project managers use the terms “resource” and“person” interchangeably, but people are only one kind of resource.The project could include computer resources (like sharedcomputer room, mainframe, or server time), locations (trainingrooms, temporary office space), services (like time fromcontractors, trainers, or a support team), and special equipmentthat will be temporarily acquired for the project. Most projectschedules only plan for human resources—the other kinds ofresources are listed in the resource list, which is part of the projectplan.

One or more resources must be allocated to each task. Todo this, the project manager must first assign the task to peoplewho will perform it. For each task, the project manager must identifyone or more people on the resource list capable of doing that task

35

and assign it to them. Once a task is assigned, the team memberwho is performing it is not available for other tasks until theassigned task is completed. While some tasks can be assigned toany team member, most can be performed only by certain people.If those people are not available, the task must wait.2.6 3.2.2. Identify Dependencies:

Once resources are allocated, the next step in creating aproject schedule is to identify dependencies between tasks. A taskhas a dependency if it involves an activity, resource, or workproduct that is subsequently required by another task.Dependencies come in many forms: a test plan can’t be executeduntil a build of the software is delivered; code might depend onclasses or modules built in earlier stages; a user interface can’t bebuilt until the design is reviewed. If Wideband Delphi is used togenerate estimates, many of these dependencies will already berepresented in the assumptions. It is the project manager’sresponsibility to work with everyone on the engineering team toidentify these dependencies. The project manager should start bytaking the WBS and adding dependency information to it: each taskin the WBS is given a number, and the number of any task that it isdependent on should be listed next to it as a predecessor. Thefollowing figure shows the four ways in which one task can bedependent on another.

Figure 3.1: Task Dependency2.7 3.2.3 Create the Schedule:

Once the resources and dependencies are assigned, thesoftware will arrange the tasks to reflect the dependencies. Thesoftware also allows the project manager to enter effort andduration information for each task; with this information, it cancalculate a final date and build the schedule.

36

The most common form for the schedule to take is a Gantt chart.The following figure shows an example:

Figure 3.2: Gantt Chart

Each task is represented by a bar, and the dependenciesbetween tasks are represented by arrows. Each arrow either pointsto the start or the end of the task, depending on the type ofpredecessor. The black diamond between tasks D and E is amilestone, or a task with no duration. Milestones are used to showimportant events in the schedule. The black bar above tasks D andE is a summary task, which shows that these tasks are twosubtasks of the same parent task. Summary tasks can containother summary tasks as subtasks. For example, if the team usedan extra Wideband Delphi session to decompose a task in theoriginal WBS into subtasks, the original task should be shown as asummary task with the results of the second estimation session asits subtasks.

37

The following figure shows an example of a Gantt chart created inMicrosoft Projects :

Figure 3.3 Gantt Chart drawn using Microsoft Project.

3

4

5

6 3.2.4 RISK PLAN

A risk plan is a list of all risks that threaten the project, alongwith a plan to mitigate some or all of those risks. Some people saythat uncertainty is the enemy of planning. If there were nouncertainty, then every project plan would be accurate and everyproject would go off without a hitch. Unfortunately, real lifeintervenes, usually at the most inconvenient times. The risk plan isan insurance policy against uncertainty.

Once the project team has generated a final set of risks, theyhave enough information to estimate two things: a rough estimateof the probability that the risk will occur, and the potential impact ofthat risk on the project if it does eventually materialize. The risks

38

must then be prioritized in two ways: in order of probability, and inorder of impact. Both the probability and impact are measuredusing a relative scale by assigning each a number between 1and 5.

These numbers are arbitrary; they are simply used tocompare the probability or impact of one risk with another, and donot carry any specific meaning. The numbers for probability andimpact are assigned to each risk; a priority can then be calculatedby multiplying these numbers together. It is equally effective toassign a percentage as a probability (i.e. a risk is 80% likely tooccur) and a real duration for impact (i.e. it will cost 32 man-hours ifthe risk occurs). However, many teams have trouble estimatingthese numbers, and find it easier to just assign an arbitrary valuefor comparison.

Many people have difficulty prioritizing, but there is a simpletechnique that makes it much easier. While it’s difficult to rank all ofthe risks in the list at once, it is usually not hard to pick out the onethat’s most likely to occur. Assign that one a probability of 5. Thenselect the one that’s least likely to occur and assign that one aprobability of 1. With those chosen, it’s much easier to rank theothers relative to them. It might help to find another 5 and another1, or if those don’t exist, find a 4 and a 2. The rest of theprobabilities should start to fall in place. Once that’s done, the samecan be done for the impact.

After the probability and impact of each risk have beenestimated, the team can calculate the priority of each risk bymultiplying its probability by its impact. This ensures that thehighest priority is assigned to those risks that have both a highprobability and impact, followed by either high-probability risks witha low impact or low-probability risks with a high impact. This isgenerally the order in which a good project manager will want to tryto deal with them: it allows the most serious risks to rise to the topof the list.

This can be very easily done using tools like MicrosoftProject or even by using any spreadsheet package that providessome basic statistical functions.

3.3 DEVELOPING THE PROJECT BUDGET.

If scheduling is an art then costing could be considered ablack art. Some projects are relatively straightforward to cost butmost are not. Even simple figures like the cost per man/hour oflabour can be difficult to calculate.

39

Accounting, costing and budgeting are extensive topics inthemselves. Some fundamental principles to keep in mind arederived from accounting practices:

• The concept of 'prudence' – you should be pessimistic in youraccounts (“anticipate no profit and provide for all possiblelosses”).Provide yourself with a margin for error and not just showthe best possible financial position. It’s the old maxim: promise low-deliver / high once again

• The 'accruals' concept- revenue and costs are accrued ormatched with one another and are attributed to the same point inthe schedule. For example if the costs of hardware are in yourbudget at the point where you pay the invoice, then ALL the costsfor hardware should be “accrued” when the invoice is received.

• The ‘consistency’ concept. This is similar to accruals but itemphasises consistency over different periods. If you change thebasis on which you count certain costs you either need to revise allprevious finance accounts in line with this or annotate the changeappropriately so people can make comparisons on a like-for-likebasis.

Note that the principles are listed in order of precedence. If theprinciple of consistency comes into conflict with the principle ofprudence, the principle of prudence is given priority.

3.3.1 Costing:

At a basic level the process of costing is reasonably simple.You draw up a list of all your possible expenditure and put anumerical value against each item; the total therefore representsthe tangible cost of your project. You may also however need toconsider “intangible” items.

Tangible costs:

• Capital Expenditure – any large asset of the project which ispurchased outright. This usually includes plant, hardware, softwareand sometimes buildings although these can be accounted for in anumber of ways.

• Lease costs – some assets are not purchased outright but areleased to spread the cost over the life of the project. These shouldbe accounted for separately to capital expenditure since the projector company does not own these assets.

• Staff costs – all costs for staff must be accounted for and thisincludes (but is not limited to): salary and pension (superannuation)

40

costs; insurance costs; recruitment costs; anything which can betied directly to employing, training and retaining staff.

• Professional services –all large-scale projects require the inputof one or more professional groups such as lawyers oraccountants. These are normally accounted for separately since aclose watch needs to be kept upon expenditure in this area.Without scrutiny the costs of a consultant engineer, accountant orlawyer can quickly dwarf other costs.

• Supplies and consumables – regular expenditure on supplies isoften best covered by a single item in your budget under whichthese figures are accrued. They are related to overhead below.

• One-off costs – one-off costs apply to expenditure which is notrelated to any of the above categories but occurs on an irregularbasis. Staff training might be an example. While it might beappropriate to list this under staff costs you might wish to track itindependently as an irregular cost. The choice is yours but theprinciples of prudence and consistency apply.

• Overheads – sometime called indirect costs, these are costswhich are not directly attributable to any of the above categories butnever-the-less impact upon your budget. For example it may not beappropriate to reflect the phone bill for your project in staff costs,yet this still has to be paid and accounted for. Costing foroverheads is usually done as a rough percentage of one of theother factors such as “staff costs”.

Intangible costsIt has become fashionable to account for “intangible” assets on thebalance sheets of companies and possibly also projects. Theargument goes like this: some contributions to a project areextremely valuable but cannot necessarily have a tangible valueassociated with them. Should you then account for them in thebudget or costing? The “prudence” principle says yes butpracticality says “no”. If you are delving this murky area ofaccountancy you should seek professional help and advice.

Typical things you might place in the budget under intangibles are“goodwill” and “intellectual property”. Personnel-related figures area frequent source of intangible assets and so you might find thingslike “management team”, “relationships” and “contacts” on anintangibles balance sheet.

3.3.2 Budgeting:

Once you have costed your project you can then prepare anappropriate budget to secure the requisite funds and plan your cash

41

flow over the life of the project. An accurate cost model will ofcourse entail a fairly detailed design or at the very leastrequirement specification so that you can determine your scope ofwork. This is normally completed well into the design phase of theproject.

You must be extremely careful with initial estimates andalways follow the “promise low / deliver high” commandment.

Costing and budgeting follow the iterative life cycle as doother tasks within the project. As you refine your design, so you willneed to refine the costing which is based upon it.

As in scheduling, you need to build in adequate contingency(reserves) to account for unexpected expenditure. For example, ifdue to a failure in the critical path a task is delayed and a milestone(like software purchase) falls due in the month after it wasscheduled. This can wreck your carefully planned cash flow. But ifyou have carefully budgeted your project then variations should berelatively easy to spot and cope with as they arise.

Just as in scheduling you should have regular budgetreviews which examine the state of your finances and yourexpenditure to date and adjust the planned budget accordingly.

Regardless of circumstance, a number of basic philosophiescan help your budgeting immensely by protecting it from subjectivereview. By understanding concepts, and making sure that everyoneinvolved understands them, you’ll be on the right track to anaccurate projection:

Project costs and project budgets are two different things.Always start by identifying project costs.

Project costs are not defined solely in monetary amounts.Include actual amounts, with shipping and taxes, forsoftware or hardware purchases that must be made. If you’repro-rating the costs of using pre-existing hardware andsoftware tools, include it in number of hours. Likewise,developer effort costs are recorded in hours, not dollars.

Once you’ve laid out your costs, identify your risks andassign a percentage reflecting how much each risk factormay affect the project as a whole, or a portion of the project.Each development team should have a risk value assignedto it, to cover reasonable costs such as hiring the occasionalcontractor to get a timeline under control, unforeseenovertime, and so on.

Your budget, then, is the total of the costs, as transcribedinto a monetary figure, plus the total risk percentage of that

42

cost. Define conversion values that you use to representequipment pro-rating and development times.

Your budget is not an invoice. Once you’ve determined thehard figures involved, leave it up to your company’s businessrepresentatives to make adjustments for profits. Make surethey understand your figures reflect actual costs.

A budget should always be labeled as an estimate, until it isfinalized and approved. This helps to manage expectationsand prevent miscommunications from being written in stone.

A single person does not create a budget. At the very least,all of the following should be consulted: lead developer,project manager, and a business-side driver.

3.4 MONITORING AND CONTROLLING THE PROJECT

To appreciate how project control works you must firstunderstand that, despite all the effort devoted to developing andgaining commitment to a plan, there is little chance that theresulting project will run precisely according to that plan.

This doesn’t mean that you will fail to achieve the objectivesof the plan – on the contrary, you must have a very high level ofconfidence that you can achieve those objectives and deliver thefull scope, fit for purpose, on time and to budget.

The plan describes what you would like to do but it modelsjust one of the infinite number of routes from where you are now towhere you want to be. In practice your project will follow a differentroute to the one shown in your plan, you don’t know which one, butyou will need control to make sure it is a route that takes you towhere you need to be, when you need to be there, and at a costyou can afford.

The power of the plan is that it gives you a baseline againstwhich you can compare actual achievement, cost and time anddetermine the amount of deviation from plan and hence takecorrective action if required.

The essential requirement for control is to have a planagainst which progress can be monitored to provide the basis forstimulating management action if the plan is not being followed.Control then becomes a regular, frequent iterationof: Creating the right environment for control.

43

Figure 3.4 : Project Control

The basic requirements for control are:

a plan that is:

- realistic

- credible

- detailed enough to be executed

- acceptable to those who must execute it (Project Managerand Project Teams)

- approved by those who are accountable for itsachievement (the SRO/ Project Board);

a process for monitoring and managing progress andresource usage;

a project management organisation of appropriately skilledpeople with sufficient authority and time to plan, monitor,report, take decisions and deal with exceptions;

a process to make minor corrections and adjustments todeal with minor deviations and omissions from the plan;

the commitment of those who will provide the resourcesindicated in the plan ( SRO, Project Board, Stakeholders andresource ‘owners’ in the parent organisation and its relatedagencies);

explicit authority to proceed granted by those who areaccountable for the project.

In all but the smallest or shortest projects you should thinkabout how to break your project into manageable ‘chunks’ calledstages. Every project will have a minimum of two stages – the firstbeing Project Initiation. A large project may have a number ofstages, each of which has its own stage plan. When designing yourproject’s stage structure look for points where the Project managershould:

review achievements to date and assess project viability

take key decisions outside the level of authority of theProject Manager

PlanningMonitoring

&evaulation

Taking Correctiveaction &

Reporting

44

approve a more detailed plan for the next phase of workcommit resources in accordance with the project or stageplan

assess the impact of some significant external event that willinfluence the project (eg: legislation, decision point in otherproject, review of business operation).

The Project Manager will also be able to identify stageboundaries by thinking about how far ahead is it sensible to plan inthe fine detail needed for day to day control. In practice, thedetailed plan for a stage will be produced towards the end of thepreceding stage, when the information needed for planning isavailable.

3.4.1 Checkpoints:

Checkpoint reports are produced by team managers /leaders for the Project Manager who needs to have early warningof deviations from plan and other problems affecting the projectteam. Checkpoints provide regular, frequent comparison of actualprogress, resource usage and forecasts against plans. Theyprovide information for the Project Manager to apply control, eg bycorrecting small deviations from the plan. The basic purpose of acheckpoint is to answer the questions:

‘What is going according to plan?’ ‘What is not going to plan?’ ‘What is likely not to go to plan?’

Checkpoints are essential controls – missed checkpoints areusually an early sign of a failing project. The information gatheredat checkpoints should be documented in Checkpoint Reports andused in the preparation of Highlight Reports.

3.4.1.1 Checkpoint design:

There are many different ways of conducting Checkpoints -they might be, but do not have to be, achieved through writtenreports and meetings. Each project must use an approach thatbalances the need for communication and control against too muchmanagement interference in work in progress. Checkpoint designwill cover:

Frequency of reporting Timing (eg: time and day of week) Information required from team members (oral reports,

timesheets, written reports) Method of conducting checkpoint (eg informal chats, formal

meetings, phone, fax, email)

45

Participation (Project Manager? Project Assurance? TeamMembers? Suppliers?)

Content of a report to be used to communicate the findingsof the Checkpoint.

The Project Manager should set Checkpoint frequencydepending on the intensity of activity. Checkpoint frequenciesranging from fortnightly (eg during procurement phases) down todaily (eg during implementation and training) are possible within thesame project.

3.4.2 Handling significant deviations from plan:

Project Board members are usually senior managers withlimited time to devote management of the project. In order toachieve ‘management by exception’ the Project Manager should begiven authority to deal with the inevitable small deviations fromplan. For larger deviations, such as those resulting from requestsfor change, poor estimation, delays in deliveries by externalagencies. The Project Manager will require an agreed exceptionhandling process. This will involve:

Setting delegated limits (eg. cost and time ‘Tolerances’): TheProject Board should set limits to the allowable deviationsfrom planned cost and schedule so that the Project Managerknows how much delegated authority is available to managedeviations from plan;

Exception reporting: The Project Manager may use anexceptional Highlight Reports to notify any forecast (oractual) deviations from plan beyond delegated limits.Positive sorts of exception should also be reported in thisway eg: finishing work early or using less resource thanplanned.

Exception planning and decision making: The managementmay wish the Project Manager to create a new plan toreplace the current one if it is no longer viable. This planwould b e submitted for a decision to proceed.

3.4.3 Monitoring System Performance:

A potential problem when software systems are involved isthe potential of the systems not being able to handle increasedvolumes of data in the future. To take care of this, performancemonitoring should be a part of all softwares that are likely to grow insize, identifying potential future bottlenecks in the system, includinglack of disk space, lack or processing power, approachingtransaction limits, long before they become a problem, so correctiveaction can be taken.

46

This process is very complex because softwares will grow insize due to systems being installed incrementally (e.g., they may beinstalled at a pilot location first) and due to future increases innumber of customers over time. It is also complex because newtechnology may become available that handles greater capacity butthat will incur additional costs to the organization to implement. It isproposed that information required for this planning be kept in aPerformance and Adaptability Plan document that identifies futureprojections of increases in number of customers handled by thesoftware, bottlenecks identified so far, and contingency plans forresolving anticipated future performance problems. ThePerformance and Adaptability Plan document would be used bybusiness planners who would project increases in numbers ofcustomers, performance monitors who identify bottlenecks insystems, and capacity planners who would identify requirements forchanges to hardware and or system software.

3.5. THE PROJECT COMMUNICATION PLAN

Good communications among all stakeholders is key for thesuccess of a project. It’s important to ensure your project teamdevelops a communication plan so that lack of communication doesnot derail your goals.

Even though you may have identified and analyzed yourstakeholders and determined the most effective communicationsvehicles – without a well developed and implementedcommunication plan, you may have a recipe for disaster. So howdo you develop a communication plan to ensure your project’ssuccess?

Following are the two types of communication plans tosupport and enhance communications throughout your project. Asdiscussed in previous installments, the first step in building yourplan is to identify your project stakeholders and determine the bestcommunications vehicle. Next, you build your plan.

3.5.1 Two Types of Communications Plans for Your Project:

For all sized projects, a well-structured communications planis a must from the beginning. Projects offer multiple opportunitiesfor communications to your key stakeholders, and we recommendexploring two types of communication plans for your project toexploit these opportunities.

1. Regular or Ongoing Communication Plan2. One-time or Event-driven Communication Plan

47

3.5.2 Building Your Plan:

Regular or Ongoing Communications:Regular, or ongoing, communications include those

opportunities you have to communicate to your project teammembers, sponsors, steering committee members, and other keystakeholders on a regular basis. These types of communicationcould include your regular status reports, scheduled project teammeetings, monthly updates with the steering committee, or regularlyscheduled campus updates on a project. Use your stakeholderanalysis to develop these routine and ongoing communications forthe project.

Review this plan at regular intervals (quarterly) to ensurethat you are adequately communicating to those stakeholders whoare closest to the project. The chart on the next page provides anexample of the types of communications to consider for yourregular and ongoing communications. Don’t forget to include yourregular meetings and even one-on-ones that you may have withyour sponsor.

Communications

Purpose Audience Author Communication vehiclelocation

Frequency

Monthlystatus reportstomanagement

To keepseniorleadershipinformedabout theprojectsprogress

SteeringcommitteeExecutivecommittee

ProjectManager

- E-mails- Websitepostings

Monthly

Weeklyschedule

Monitor theprogressand report.

Projectmanagementteam

ProjectManager

-E-mails- postings onwebsite- meetings

Weekly

Project Teamcalendar

Keepprojectparticipantsaware ofthe keyprojectdeadlinesto helpthemmanagetheirschedule

ProjectparticipantsSteeringcommittee

Projectcoordinator

Postings intherespectivemembersfolder

As andwhenneeded.

Figure 3.5 : Sample communication plan

48

One-time or Event-driven Communications:During the life of any project, opportunities arise for one-time

or event-driven communications. Work with your project team toidentify those opportunities, like the example timeline. This plancould also include critical issues sessions, vendor meetings,training schedules, and roll-out schedules.

To gain the most advantage from the communicationsopportunities for your project, review this portion of yourcommunication plan every month with your project team. Reviewthe past month, and then look forward at least six months to ensurethat as your project plan changes, you are able to capitalize onevery communication opportunity.

When developing your communications plan keep in mind that thekey is to always have the receiver as the focal point—not thesender. Make your communications deliberate and focused. Bymaking sure that your plan is clear and thoroughly outlined, you canhelp reduce the number of problems and surprises that pop-up andhave a project as successful as a perfect soufflé.

3.6 PROJECT METRICS

Metrics are a set of quantifiable parameters which are usedto measure the effectiveness of a project or undertaking. Valuesare obtained for the parameters for multiple instances of the sameentity and they are compared and interpreted as to the change inthe effectiveness. For example, if there are multiple versions of aproduct, one metric could be the user satisfaction level (say 1 to 5,1 being least happy and 5 being very happy)with the user interfacefor each of the versions. The effectiveness of the changes in theuser interface can be measured by the satisfaction level of theusers with each of the versions.

Project metrics are in-process or project execution measuresthat are collected, analysed and used to drive project processimprovement.

6.1.1 3.6.1 Reasons for Project Metrics:

Project metrics require time and effort and so that work is done forusually one of these reasons:

To provide clear and tangible project status informationabout project schedule and cost

To identify areas for project process improvement

To demonstrate the results of process improvement efforts

49

To collect a database of project metrics to analyse trendinformation or provide historic comparators and perhapsused for parametric estimates

To collect project metrics without a clear plan of future actionto use those metrics is simply wasting time and effort. In short, onlycollect project metrics that will be used to drive project processimprovements.

6.1.2 3.6.2 Key Project Metrics:

Senior management will often wish to see regular reports ofproject progress against time and cost measures. Some projectmanagement methodologies go into some detail with these metricsincluding planned versus forecast, cost variance, schedule varianceand earned value. However, more generally, key projectmanagement metrics include:

Schedule - delivery date and slippage in days from originaldelivery date

Cost - actual budget versus original budget

Resource - effort, how much time people have used on theproject

Scope - changes to project as measured through numberand type of controlled changes made

Quality - quality defects and documentation

Software - a specialised subject with many potentialmeasures such as lines of code, code complexity andfunction point

Defects - number and type of problems or issues recordedfor the technology project during its test stage and warrantyperiod or a defined time period

Other metrics associated with normal operation such asavailability, performance or support call resolution properly belongwith service metrics rather than project metrics.

Project metrics selected should reflect the voice of thecustomer (customer needs), as well as ensure that the internalmetrics selected by the organization are achieved. Metrics selectedshould be simple and straightforward and meaningful. Metricsselected should create a common language among diverse teammembers.

When drafting metrics for a particular project one shouldconsider how the metrics are connected and related to key

50

business metrics. Typically there is no one metric that fits all therequirements for a particular situation.

3.6.3 Developing Project Metrics:

The most common approach used by teams is to understandthe problem statement, brainstorm metrics, and finally decide whatmetrics can help them achieve better performance. The team thenreviews these metrics with executive management to ensure thatthey are in synergy with the overall strategy of the business, and aniterative approach may be utilized.

Care should be exercised in determining what is measured.Metrics should be based on what, in fact, needs to be measured toimprove the process, rather than what fits the current measurementsystem. Metrics need to be scrutinized from the value they add inunderstanding a process.

3.7 REPORTING PERFORMANCE & PROGRESS

Performance reporting involves collecting, processing andcommunicating information to key stakeholders, regarding theperformance of the project. Performance reporting can beconducted using various tools and techniques, most of which havebeen already described in the previous paragraphs. The mostwidely used techniques for performance reporting are:

Performance review meetings that take place to assess theproject’s progress or/and status

Variance analysis which is about comparing actual project results(in terms of schedule, resources, cost, scope, quality and risk)against planned or expected ones.

Earned Value Analysis (EVA) used to assess project performancein terms of time (schedule) and cost (or resources).

Financial and Output Performance Indicators used to measurefinancial and physical progress of the project

Information of project’s performance is usually communicated viaProgress Reports and Project Status Reports which aredescribed in the paragraphs below.

The Progress Report is a document prepared by the ProjectTeam members (in case of in-house production) or by theManagement Team of the Contractor (in case that theimplementation of the project is totally outsourced) to provide

51

regular feedback to the Project Manager regarding the progress ofthe project. Progress reports should be submitted on a regularbasis to enable the Project Manager to update the ActivitiesSchedule, identify any schedule problems or potential problemsand act proactively for their resolution. Progress Reports areusually asked to be submitted every two weeks or every month,when the project is implemented with own resources. However, incase that the project is implemented by a Contractor, the progressreports are usually asked every three or six months. Generally, aProgress Report should include the following information:

- Reporting period to which it refers- Project Title- Project Manager’s name- Authors of the report- Date of submission- Project synopsis (i.e. project goals and objectives, expected

results, project activities, duration, etc.)

Project progress in the reporting period (i.e. activities/ tasksexecuted, actual work accomplished, deliverables submitted,deviations for baseline schedule, estimation of the effort required tocomplete activities/ tasks)

Work programme for the following reporting period (i.e.activities/ tasks to be executed, deliverables to be submitted,schedule estimates for key milestones, etc.)

Updated/ revised Activities Schedule showing thepercentage of work completed so far and the estimated start orfinish dates for activities/ tasks.

It should be noted that in case of small projects with only fewteam members, the Progress Report can be substituted bypersonal judgment and observations of the Project Manager or byday-to-day discussions with the team members on the progress ofthe deliverables. On the contrary, in case of large and complexprojects, where progress reporting is an important aspect ofcommunication management, the Progress Reports should beformally submitted to the Project Manager by the Team Manager(s)(or by the Contractor), who have to prepare them by collecting therelative progress information from individual team members.

3.7.1 Project Status Report:

The Project Status Report is a document prepared by theProject Manager - using the information provided by the ProgressReports - to present the status of the project to key stakeholders,including the Project Steering Committee, the Project Owner and

52

the Funding Agency. Depending on the duration and size of theproject, as well as on specific communication requirements of theProject Owner or/and the Funding Agency, the Status Report canbe prepared monthly, quarterly or biannually. Usually, StatusReports are prepared with the same or less frequency thanProgress Reports since they require input from them.

The aim of the Project Status Report is to:

-Provide an overview of project’s progress up to date

- Ensure that the key stakeholders are regularly informed on theprogress of the project

- Inform the key stakeholders about issues that require immediateaction or resolution

Normally the Status Report becomes the point of discussionfor the Status Meeting, which is a regularly scheduled event, wherethe Project Manager presents the status of the project to theSteering Committee (and maybe to the Project Owner or /and theFunding Agency). In these meetings the Project Manager can invitemembers of the Project Team who have expertise in a certain areaof the discussion. It is, however recommended that the ProjectManager invites periodically the Project Team to review the statusof the project, discuss their accomplishments and communicate anyissues or concerns in an open, honest and constructive forum. Onlarge projects where gathering the entire team is not alwayspossible, the Project Team members can be represented in themeeting by the respective Team Manager(s), who cancommunicate the status of their team work since they have a betterinsight into the day-to-day activities of their team members.

53

4

PROJECT RISK MANAGEMENT

Unit Structure:

4.0 Objectives

4.1 Introduction

4.2 The Importance of Project Risk Management

4.2.1 Processes and outputs

4.3 Risk Management Planning

4.4 Common Sources of Risk in Information Technology projects

4.4.1 Categories of Risk

4.4.2 Risk Breakdown Structure

4.5 Risk Identification

4.5.1 Suggestions For Identifying Risks

4.5.2The Risk Register

4.6 Qualitative Risk Analysis

4.6.1 Using Probability/Impact Matrix To Calculate RiskFactors

4.6.2 Top Ten Risk Item Tracking

4.6.3 Expert Judgment

4.7 Quantitative Risk Analysis

4.7.1 Decision Trees and Expected monetary Value

4.7.2 Simulation

4.7.3 Sensitivity Analysis

4.8 Risk Response Planning

4.9 Risk Monitoring and Control

4.10. Using Software to Assist in Project Risk Management

4.11 Summary

4.0 OBJECTIVES

After reading this chapter you will be able to:1. Understand what risk is and the importance of good project

risk management

54

2. Discuss the elements involved in risk management planningand contents of a risk management plan.

3. List common sources of risks on information technologyprojects

4. describe the risk identification process, tools and techniquesto help identify project risks and the main output of riskidentification-risk register

5. Discuss the qualitative risk analysis process and explain howto calculate risk factors, create probability impact matrixes,apply the top ten risk item tracking techniques, and useexpert judgment to rank risks

6. Explain quantitative risk analysis process and how to applydecision trees, simulation, and sensitivity analysis to quantifyrisks

7. Provide examples of using different risk response planningstrategies to address both negative and positive risks

8. Discuss the components of risk monitoring and control

9. Describe how software can assist in project riskmanagement

4.1 INTRODUCTION

Managing risk is an integral part of good management and issomething many managers do already in one form or another.

Project risk is an uncertain event or condition that, if itoccurs, has a positive or a negative effect on at least one projectobjective. A risk may have one or more causes and, if it occurs, oneor more impacts. Risk management is the systematic process ofplanning for, identifying, analyzing, responding to, and monitoringproject risks. It involves processes, tools, and techniques that willhelp the project manager maximize the probability and results ofpositive events and minimize the probability and consequences ofadverse events as indicated and appropriate within the context ofrisk to the overall project objectives of cost, time, scope and quality.Project risk management is most effective when first performedearly in the life of the project and is a continuing responsibilitythroughout the project’s life cycle.

4.2 THE IMPORTANCE OF PROJECT RISKMANAGEMENT

The project risk management process helps projectsponsors and project teams make informed decisions regarding

55

alternative approaches to achieving their objectives and the relativerisk involved in each, in order to increase the likelihood of successin meeting or exceeding the most important objectives (e.g. time)sometimes at the expense of other objectives (e.g. cost).

Risk Management provides a structured way of identifyingand analyzing potential risks, and devising and implementingresponses appropriate to their impact. These responses generallydraw on strategies of risk prevention, risk transfer, impact mitigationor risk acceptance. Within a single project or proposal each ofthese strategies may have application for different individual risks.Risk management encourages the project team to take appropriatemeasures to:

1. Minimize adverse impacts to project scope, cost, and schedule(and quality, as a result).

2. Maximize opportunities to improve the project’s objectives withlower cost, shorter schedules, enhanced scope and higherquality.

3. Minimize management by crisis.

Project risk management is the art and science of identifying,analyzing and responding to risk throughout the life of a project andin the best interest of meeting the project objectives. A frequentlyoverlooked aspect of project management, risk management canoften result in significant improvements in the ultimate success ofprojects .Risk management can have a positive impact on selectingprojects, determining scope of projects and developing realisticschedules and cost estimates. It helps project stakeholdersunderstand the nature of the project, involves team members indefining the strengths and weakness , and helps to integrate theother project management knowledge areas.

Before you can improve project risk management, you mustunderstand what risk is .A basic dictionary definition says that riskis “the possibility of loss or injury”. This definition highlights thenegativity often associated with risk and suggests that uncertaintyis involved. Project risk management involves understandingpotential problems that might occur on the project and how theymight impede project success. The PMBOK Guide 2004 refers tothis type of risk as a negative risk. However, there are also positiverisks, which can result in good things happening on a project. Ageneral definition of a project risk , therefore , is an uncertainty thatcan have a negative or positive effect on meeting projectobjectives.

56

Some organizations or people have a neutral tolerance forrisk, some have an aversion to risk, and others are risk seeking.These three preferences for risk are part of the utility theory of risk.

Risk utility or risk tolerance is the amount of satisfaction orpleasure received from a potential payoff. The following figureshows the basic difference between risk averse, risk neutral, andrisk seeking preferences. The y-axis represents utility, or theamount of pleasure received from taking a risk. The x-axis showsthe amount of potential payoff, opportunity, or dollar value of theopportunity at stake.

Utility rises at a decreasing rate for a risk averse person.That is when more payoff or money is at stake ,a person ororganization that is risk averse gains less satisfaction from risk, orhas lower tolerance for the risk. Those who are risk seeking have ahigher tolerance for the risk, and their satisfaction increases whenmore payoff is at stake. A risk seeking person prefers outcomesthat are more uncertain and is often willing to pay penalty to takerisk. A risk neutral person achieves balance between risk andpayoff..

Risk –Averse Risk-Neutral Risk-Seeking

Risk utility function and risk preference

The goal of project risk management can be viewed asminimizing potential negative risks while maximizing potentialpositive risks. The term known risks is some times used to describerisks that the project team has identified and analyzed .

4.2.1 Processes and outputs:

This matrix shows the six main processes and all of thedeliverables associated with project risk management

Process Output(deliverables)

Risk managementplanning

Risk management plan(RMP)

57

Risk identification Risk Register (Register)

Qualitative risk analysis Risk Register (updates)Prioritized list of risks classified ashigh, moderate, or low

Quantitative risk analysis Quantitative Risk Analysis ReportsNumerical analysis of the project’slikelihood of achieving its overallobjectives(Risk Register updates)

Risk response planning 1- Risk Register (updates)2- Project Management Plan(updates)3- Project Risk Management Plan(updates)4- Risk-related contractualagreementsThe outcome may result in one ormore of the following: residual risks,secondary risks, change control,contingency reserve (amounts oftime or budget needed).

Risk monitoring andcontrol

Risk Register (updates)The outcome may result inworkaround plans, correctiveactions, programming changerequest (PCR), and updates to riskidentification checklists for futureprojects

4.3 RISK MANAGEMENT PLANNING

Risk management planning is the process of deciding how toapproach and plan for risk management activities for a project, andthe main output of this process is a risk management plan A riskmanagement plan documents the procedure for managing riskthroughout the project.

The project team should hold several planning meeting earlyin the project’s life cycle to help develop the risk management plan.The project team should review the project documents as well ascorporate risk management policies, risk categories, lessonslearned reports from past projects and templates for creating riskmanagement plan.

Careful and explicit planning enhances the possibility ofsuccess of the other risk management processes. RiskManagement Planning is the process of deciding how to approach

58

and conduct the risk management activities for a project. Planningof risk management processes is important to ensure that the level,type, and visibility of risk management are commensurate with boththe risk and importance of the project to the organization, to providesufficient resources and time for risk management activities, and toestablish an agreed-upon basis for evaluating risks. The RiskManagement Planning process should be completed early duringproject planning, since it is crucial to successfully performing theother processes described in this handbook.

The result of Risk Management Planning is a RiskManagement Plan. The risk management plan identifies andestablishes the activities of risk management for the project in theproject plan (RMP)

A risk management plan summarizes how risk managementwill be performed on a particular project. Like other specificknowledge area plans it becomes a subset of project managementplan The following table lists the general topics that a riskmanagement plan should address It is important to clarify roles andresponsibilities, prepare budget and schedule estimates for risk-related work, and .identify risk categories for consideration. It isalso important to describe how risk management will be done,including assessment of risk probabilities and impacts as well ascreation of risk related documentation.

Methodology: How will risk management will be performed on thisproject?. What tools and data sources are available andapplicable?

Roles and responsibilities: who are the individuals responsible forimplementing specific tasks and providing deliverables related torisk management

Budget and schedule: What are the estimated costs andschedules for performing risk related activities?

Risk Categories: What are the main categories of risk that shouldbe addressed on this project?. Is there a risk breakdown structurefor the project

Risk Probability and Impact: How will the probabilities andimpacts of risk items be assessed?. What scoring and interpretationmethods will be used for the qualitative and quantitative analysis ofrisks?

Risk Documentation: What reporting formats and processes willused for risk management activities?

59

In addition to risk management plan many projects alsoinclude contingency plans, fallback plans, and contingencyreserves. Contingency plans are predefined actions that the projectteam will take if an identified risk event occurs. For example ,if theproject team knows that a new release of a software package maynot be available in time for them to use it for their project, theymight have a contingency plan to use the older version of thesoftware.

Fallback plans are developed for risks that have a highimpact on meeting project objectives and are put in to effect ifattempts to reduce risks are not effective. For example , a newcollege graduate might have a main plan and several contingencyplans on where to live after graduation, but if none of the planswork out a fallback plan might be to live at home for a while.Sometimes contingency plans and fallback plans are usedinterchangeably.

Contingency reserves or contingency allowances areprovisions held by the project sponsor or organization to reduce therisk of cost or schedule overruns to an acceptable level. Forexample if a project appears to be off course because the the staffis inexperienced with some new technology and the team had notidentified it as a risk ,the project sponsor may provide additionalfunds from contingency reserves to hire an outside consultant totrain and advise the project staff in using the new technology.

4.4 COMMON SOURCES OF RISK IN INFORMATIONTECHNOLOGY PROJECTS

Several studies show that IT projects share some commonsources of risk. The Standish Group developed an IT successpotential scoring sheet based on potential risks. Other broadcategories of risk help identify potential risks.

Information Technology Success Potential Scoring Sheet

Success Criterion Relative Importance

User Involvement 19

Executive Management support 16

Clear Statement ofRequirements

15

Proper Planning 11

Realistic Expectations 10

Smaller Project Milestones 9

Competent Staff 8

60

Ownership 6

Clear Visions and Objectives 3

Hard-Working, Focused Staff 3

Total 100

The Standish Group provides specific questions for eachsuccess criterion to help decide the number of points to assign to aproject. For example the five questions related to user involvementinclude the followingDo I have the right user(s)?Did I involve the users early and often?Do I have a quality relationship with user(s)?Do I make involvement easyDid I find out what the user(s) need(s)?

The number of questions corresponding to each successcriterion determines the number of points each positive response isassigned. For example in the case of user involvement there arefive questions . For each positive reply , you would get(19/5) 3.8points . !9 represents the weight of the criterion and five representsthe number of questions. Therefore ,you would assign a value tothe user involvement criterion by adding 3.8 points to the score foreach question you can answer positively.

4.4.1 Categories of Risk:

A broad categories of risks are described on thequestionnaires developed by many organizations. Some of themare given below.

� Market risk: If the information technology project is to produce anew product or service will it be useful to the organization ormarketable to others?. Will user accept the product or service?. Willsomeone else make a better product or service faster, making theproject a waste of time and money.

� Financial risk: Can the organization afford to undertake theproject?. How confident are the stakeholders in the financialprojections?. Will the project meet NPV,ROI, and paybackestimates?. If not van the organization afford to proceed theproject?. Is this project the best way to use the organization’sfinancial resources?

� Technology risk: Is the project technically feasible?. Will it usemature, leading edge or bleeding edge technologies? When willdecisions be made on which technology to use? Will H/w, S/w andnetwork function properly?. You can also breakdown thetechnology risk into h/w, s/w, and network technology if required.

61

� People risk: Does the organization have or can they find peoplewith appropriate skills to complete the project successfully?. Dothey have enough experience?. Does senior management supportthe project?. Is the organization familiar sponsor/customer for theproject?. How good is the relationship with the sponsor/customer?� Structure/process risk: What is the degree of change the newproject will introduce into user areas and business procedures?How many distinct user groups does the project need to satisfy?With how many other systems does the project need to interact?Does the organization have processes in place to complete theproject successfully?

4.4.2 Risk Breakdown Structure:

� A risk breakdown structure is a hierarchy of potential riskcategories for a project. Similar to a work breakdown structure butused to identify and categorize risks. A sample shown below.

A risk break down structure is a useful tool that can helpproject managers consider potential risks in different categories.The highest level categories are business, technical, andorganizational and project management. Competitors suppliers,and cash flow are categories that fall under business risks. Undertechnical risk are the categories h/w, s/w, and network.

62

A risk break down structure provides a simple, one pagechart to help ensure a project team is considering important riskcategories related to all information technology projects.

The following table shows the potential negative riskconditions that can exist within each knowledge area.

Potential Risk Conditions Associated With Each Knowledge Area

4.5 RISK IDENTIFICATION

Risk identification involves identifying potential project risks.Risk Identification produces a deliverable — the project RiskRegister – where risks are identified that may affect the project’sability to achieve its objectives. Risk Identification documents whichrisks might affect the project and documents their characteristics.The Risk Register is subsequently amended with the results fromqualitative risk analysis and risk response planning, and is reviewedand updated throughout the project.

Participants in risk identification activities can include thefollowing, where appropriate: project manager, project teammembers, risk management team (if assigned), subject matterexperts both from the project and from outside the project team,customers, end users, other project managers, stakeholders, andrisk management experts. While these personnel are often key

63

participants for risk identification, all project personnel should beencouraged to identify risks.

4.5.1 Suggestions For Identifying Risks:

The assigned team members identify the potential risks(threats and opportunities), using� The risk breakdown structure, suitably tailored to the project.� The sample risk list� Their own knowledge of the project or similar projects.� Consultation with others who have significant knowledge of the

project or its environment.� Consultation with others who have significant knowledge of

similar projects.

There are several other tools and techniques also foridentifying risks Five common information gathering techniques forrisk identification include brainstorming ,Delphi technique,interviewing ,root cause analysis, and SWOT analysis.

1. Brain Storming:It is a technique by which a team attempt to generate ideas

or find solutions for a specific by amassing ideas spontaneouslyand with out judgment . This approach can help the group create acomprehensive list of risks to address later in the qualitative andquantitative risk analysis process. An experienced facilitator shouldrun the brainstorming session and introduce new categories ofpotential risks to keep the ideas flowing . After the ideas arecollected ,the facilitator can group and categorize the ideas to makethem more manageable

2. Delphi Technique:The Delphi Technique is used to derive a consensus among

a panel of experts who make predictions about futuredevelopments. It Provides independent and anonymous inputregarding future events. Uses repeated rounds of questioning andwritten responses and avoids the biasing effects possible in oralmethods, such as brainstorming.

3. Interviewing:Interviewing is a fact-finding technique for collecting

information in face-to-face, phone, e-mail, or instant messagingdiscussions. Interviewing people with similar project experience isan important tool for identifying potential risks.

4. SWOT Analysis: SWOT analysis (strengths, weaknesses, opportunities,and

threats) can also be used during risk identification.

64

Helps identify the broad negative risks that apply to aproject.

Applying SWOT to specific potential projects can helpidentify the broad risks and opportunities that apply in that scenarioSome other techniques for risk identification are

5. Use of checklists :The list of risks that have been encountered in previous

projects provide meaningful template for understanding risks incurrent projects.

It is important to analyze project assumptions to make surethat they are valid. Incomplete, inaccurate or inconsistentassumptions might lead to identifying more risks.

6. Diagramming Technique:This method include using cause and effect diagrams or

fishbone diagrams ,flow charts and influence diagrams .Fishbonediagrams help you trace problems back to their root cause. Processflow charts are diagrams that show how different parts of thesystem interrelate.

4.5.2 The Risk Register:

The main output of the risk identification process is a list ofidentified risks and other information needed to begin creating arisk register.

A risk register is:

� A document that contains the results of various risk management

processes and that is often displayed in a table or spreadsheetformat.

� A tool for documenting potential risk events and relatedinformation.

Risk Register Contents

� An identification number for each risk event.

� A rank for each risk event.

� The name of each risk event.

� A description of each risk event.

� The category under which each risk event falls.

� The root cause of each risk.

65

� Triggers for each risk; triggers are indicators or symptoms ofactual risk events.

� Potential responses to each risk.

� The risk owner or person who will own or take responsibility foreach risk.

� The probability and impact of each risk occurring.

� The status of each risk.Sample Risk Register

4.6 QUALITATIVE RISK ANALYSIS

� Assess the likelihood and impact of identified risks to determinetheir magnitude and priority.

� Risk quantification tools and techniques include:

� Probability/impact matrixes

� The Top Ten Risk Item Tracking

� Expert judgment

4.6.1 Using Probability/Impact Matrix To Calculate RiskFactors:

A probability/impact matrix or chart lists the relativeprobability of a risk occurring on one side of a matrix or axison a chart and the relative impact of the risk occurring on theother.

List the risks and then label each one as high, medium, orlow in terms of its probability of occurrence and its impact if itdid occur.

66

It may be useful to create separate Probability/Impact Matrixor chart for negative risks and positive risks to make sure bothtypes of risks are adequately addressed. Qualitative analysis isnormally done quickly so that the project team has to decide whattype of approach makes the most sense for their project. Toquantify risk probability and consequence, the Defense SystemsManagement College developed a technique for calculating riskfactors – the numbers that represent the overall risk of specificevents ,based on their probability of occurring and consequences tothe project if they do occur. The technique makes use ofProbability/Impact Matrix that shows the probability of risksoccurring and the impact or consequences of the risks.

Probability of a risk occurring can be estimated based onseveral factors as determined by the unique nature of each project .For example factors evaluated for potential H/W or S/W technologyrisks could include the technology not being mature, the technologybeing too complex, and an inadequate support base for developingthe technology. The impact of a risk occurring could include factorssuch as availability of fallback solutions or the consequences of notmeeting performance , cost and schedule estimates

Sample Probability/Impact Matrix

The following figure gives an example of how the risk factorswere used to graph the probability of failure and consequence offailure for proposed technologies. The figure classifies potential

67

technologies (dots on the charts) as high, medium, or low riskbased on the probability of failure and consequence of failure. Theresearchers for this study highly recommended that the US AirForce invest in the low to medium risk technologies and suggestedthat it not pursue the high risk technologies. It can be seen that therigor behind using Probability/Impact Matrix and risk factorsprovides a much stronger argument than simply stating the riskprobabilities or consequences are high, medium, or low

Chart Showing High-, Medium-, and Low-Risk Technologies

4.6.2 Top Ten Risk Item Tracking:

Top Ten Risk Item Tracking is a qualitative risk analysis toolthat helps to identify risks and maintain an awareness of risksthroughout the life of a project. Establish a periodic review of thetop ten project risk items.

The review begins with a summary of the status of top tensources of risk on the project. The summary includes each item’scurrent ranking previous ranking, number of times it appears on thelist over a period of time, and a summary of progress made inresolving the risk item since the previous review.

List the current ranking, previous ranking, number of timesthe risk appears on the list over a period of time, and a summary ofprogress made in resolving the risk item.

68

The following figure provides an example of Top Ten RiskItem Tracking chart that could be used at a management reviewmeeting for a project. This includes only the top five negative riskevents. Each risk event is ranked based on the current month,previous month, and how many months it has been in the top ten.The last column briefly describes the progress for resolving eachparticular risk item

Example of Top Ten Risk Item Tracking

4.6.3 Expert Judgment:

Many organizations rely on the intuitive feelings and pastexperience of experts to help identify potential project risks.Experts can categorize risks as high, medium, or low with orwithout more sophisticated techniques.

The main output of qualitative risk analysis is updating therisk register .The ranking column of the risk register should be filledin along with numeric value or high, medium, low for the probabilityand impact of the risk event. Additional information is often addedfor risk events, such as identification of risks that need moreattention in the near term or those that can be placed on a watchlist. A watch list is a list of risks that are low priority , but are still

69

identified as potential risks. Qualitative analysis can also identifyrisks that should be evaluated on a quantitative basis.

4.7 QUANTITATIVE RISK ANALYSIS

Often follows qualitative risk analysis, but both can be donetogether.

Large, complex projects involving leading edge technologiesoften require extensive quantitative risk analysis.Main techniques include:

Decision tree analysis Simulation Sensitivity analysis

Quantitative risk analysis is a way of numerically estimatingthe probability that a project will meet its cost and time objectives.Quantitative analysis is based on a simultaneous evaluation of theimpact of all identified and quantified risks. The result is aprobability distribution of the project’s cost and completion datebased on the identified risks in the project.

Quantitative risk analysis involves statistical techniques,primarily Monte Carlo simulation that is most widely and easily usedwith specialized software.

Quantitative risk analysis starts with the model of the project,either its project schedule or its cost estimate depending on theobjective. The degree of uncertainty in each schedule activity andeach line-item cost element is represented by a probabilitydistribution. The probability distribution is usually specified bydetermining the optimistic, the most likely and the pessimisticvalues for the activity or cost element – this is typically called the“3-point estimate.” The three points are estimated during aninterview with subject matter experts who usually focus on theschedule or cost elements one at a time. The risks that lead to thethree points are recorded for the quantitative risk analysis reportand for risk response planning. For each activity or cost element aprobability distribution type is chosen that best represents the risksdiscussed in the interview. Typical distributions usually include thetriangular, beta, normal and uniform.

4.7.1 Decision Trees and Expected monetary Value:

A decision tree is a diagramming analysis technique used tohelp select the best course of action in situations in which futureoutcomes are uncertain.

� Estimated monetary value (EMV) is the product of a risk eventprobability and the risk event’s monetary value.

70

� You can draw a decision tree to help find the EMV.

To create a decision tree and to calculate expectedmonetary value specifically, you must estimate the probabilities, ofcertain events occurring. For example in the following figure there isa 20 percent probability(P=.20) that Cliff’s firm will win the contractproject1, which is estimated to be $300,000 in profits- the outcomeof the top branch in the figure. There is an 80 percent probabilitythat it will not win the contract for the project, and the outcome isestimated to be -$40,000 meaning that the firm has to invest$40,000 into project1with no reimbursement if it is not awarded thecontract.

To calculate EMV for each project, multiply the probability bythe outcome value for each potential outcome for each project .The EMV for project 1 is 0.2($300,000)+0.8(-40,000)=$60,000-$32000=28,000

4.7.2 Simulation:

A specialized Monte Carlo simulation software program runs(iterates) the project schedule or cost estimate many times, drawingduration or cost values for each iteration at random from theprobability distribution derived from the 3-point estimates andprobability distribution types selected for each element. The MonteCarlo software develops from the results of the simulation aprobability distribution of possible completion dates and projectcosts. From this distribution it is possible to answer such questionsas:

• How likely is the current plan to come in on schedule or onbudget?

• How much contingency reserve of time or money is needed toprovide the agency with a sufficient degree of certainty?

71

• Using sensitivity analysis, which activities or line-item costelements contribute the most to the possibility of overrunningschedule or cost targets?

4.7.3 Sensitivity Analysis:

Sensitivity analysis is a technique used to show the effectsof changing one or more variables on an outcome.

For example, many people use it to determine what themonthly payments for a loan will be given different interestrates or periods of the loan, or for determining break-evenpoints based on different assumptions.

Spreadsheet software, such as Excel, is a common tool forperforming sensitivity analysis.

The following figure shows an example Excel file created toquickly show the break-even point for a product based on variousinputs-the sales price per unit, manufacturing cost per unit, andfixed monthly expenses. The current inputs result I a break-evenpoint of 6,250 units sold. Users of this spreadsheet can changeinputs and see the effects on the break-even point in chart format.Project teams often create similar models to determine thesensitivity of various project variables.

72

The main outputs of quantitative risk analysis are updates tothe risk register, such as revised risk rankings or detailedinformation behind those rankings. The quantitative analysis alsoprovides high level information in terms of the probabilities ofachieving certain projects objectives. This information might causethe project manager to suggest changes in contingency reserves .

4.8 RISK RESPONSE PLANNING

73

Risk Response Planning is the process of developingoptions, and determining actions to enhance opportunities andreduce threats to the project’s objectives. It focuses on the high-riskitems evaluated in the qualitative and/or quantitative risk analysis.In Risk Response Planning parties are identified and assigned totake responsibility for each risk response. This process ensuresthat each risk requiring a response has an owner monitoring theresponses, although a different party may be responsible forimplementing the risk handling action itself.

The project manager and the PDT identify which strategy isbest for each risk, and then design specific action(s) to implementthat strategy.

Strategies for Negative Risks or Threats include:

� Avoid: Risk avoidance involves changing the project plan toeliminate the risk or to protect the project objectives (time, cost,scope, quality) from its impact. The team might achieve this bychanging scope, adding time, or adding resources (thus relaxingthe so-called “triple constraint”).

These changes may require a Programming ChangeRequest (PCR). Some negative risks (threats) that arise early in theproject can be avoided by clarifying requirements, obtaininginformation, improving communication, or acquiring expertise.

� Transfer: Risk transference requires shifting the negative impactof a threat, along with ownership of the response, to a third party.An example would be the team transfers the financial impact of riskby contracting out some aspect of the work.

Transference reduces the risk only if the contractor is morecapable of taking steps to reduce the risk and does so. Risktransference nearly always involves payment of a risk premium tothe party taking on the risk.

Transference tools can be quite diverse and include, but arenot limited to the use of: insurance, performance bonds, warranties,guarantees, incentive/disincentive clauses, A+B Contracts, etc.

� Mitigate. Risk mitigation implies a reduction in the probabilityand/or impact of an adverse risk event to an acceptable threshold.Taking early action to reduce the probability and/or impact of a riskis often more effective than trying to repair the damage after therisk has occurred.

Risk mitigation may take resources or time and hence mayrepresent a tradeoff of one objective for another. However, it may

74

still be preferable to going forward with an unmitigated risk.Monitoring the deliverables closely, increasing the number ofparallel activities in the schedule, early involvement of regulatoryagencies in the project, early and continuous outreach tocommunities/advocacy groups, implementing value engineering,performing corridor studies, adopting less complex processes,conducting more tests, or choosing a more stable supplier areexamples of mitigation actions.

General Risk Mitigation Strategies for Technical, Cost, andSchedule Risks

Strategies for Positive Risks or Opportunities include:

� Exploit. The organization wishes to ensure that the opportunityis realized. This strategy seeks to eliminate the uncertaintyassociated with a particular upside risk by making the opportunitydefinitely happen. Examples include securing talented resourcesthat may become available for the project.

� Share. Allocating ownership to a third party who is best able tocapture the opportunity for the benefit of the project. Examplesinclude: forming risk-sharing partnerships, teams, working withelected officials, special-purpose companies, joint ventures, etc.

� Enhance. This strategy modifies the size of an opportunity byincreasing probability and/or positive impacts, and by identifyingand maximizing key drivers of these positive-impact risks. Seekingto facilitate or strengthen the cause of the opportunity, andproactively targeting and reinforcing its trigger conditions, mightincrease probability. Impact drivers can also be targeted, seeking toincrease the project’s susceptibility to the opportunity.

75

� Acceptance. A strategy that is adopted because it is either notpossible to eliminate that risk from a project or the cost in time ormoney of the response is not warranted by the importance of therisk. When the project manager and the project team decide toaccept a certain risk(s), they do not need to change the project planto deal with that certain risk, or identify any response strategy otherthan agreeing to address the risk if and when it occurs. Aworkaround plan may be developed for that eventuality.

There are two types of acceptance strategy:

1. Active acceptance. The most common active acceptancestrategy is to establish a contingency reserve, including amounts oftime, money, or resources to handle the threat or opportunity.

2- Passive acceptance. Requires no action leaving the projectteam to deal with the threats or opportunities as they occur.

i. Workaround:Workaround is distinguished from contingency plan in that a

workaround is a recovery plan that is implemented if the eventoccurs, whereas a contingency plan is to be implemented if atrigger event indicates that the risk is very likely to occur.

As with risk identification process, the team should alsoconsider residual risks, secondary risks, and risk interaction in therisk response planning process. See page 10 for details.

4.9 RISK MONITORING AND CONTROL

Risk monitoring and control keeps track of the identifiedrisks, residual risks, and new risks. It also monitors the execution ofplanned strategies on the identified risks and evaluates theireffectiveness.

Risk monitoring and control continues for the life of theproject. The list of project risks changes as the project matures,new risks develop, or anticipated risks disappear.

Typically during project execution there should be regularlyheld risk meetings during which all or a part of the Risk Register isreviewed for the effectiveness of their handling and new risks arediscussed and assigned owners. Periodic project risk reviewsrepeat the process of identification, analysis, and responseplanning. The project manager ensures that project risk is anagenda item at all PDT meetings. Risk ratings and prioritizationcommonly change during the project lifecycle.

76

If an unanticipated risk emerges, or a risk’s impact is greaterthan expected, the planned response may not be adequate. Theproject manager and the PDT must perform additional responseplanning to control the risk.

Risk control involves:�Choosing alternative response strategies �Implementing a contingency plan�Taking corrective actions �Re-planning the project, as applicable

The individual or a group assigned to each risk (risk owner)reports periodically to the project manager and the risk team leaderon the status of the risk and the effectiveness of the response plan.The risk owner also reports on any unanticipated effects, and anymid-course correction that the PDT must consider in order tomitigate the risk.

4.10. USING SOFTWARE TO ASSIST IN PROJECTRISK MANAGEMENT

Most organizations use software to create , update , anddistribute informations in their risk registers.The risk register is oftena word or excel file but it can also be part of a more sophisticateddatabase. Spreadsheets can aid in tracking and quantifying risk ,preparing charts and graphs , and performing sensitivity analysis.Software can be used to create decision trees and estimatedmonitary values.

More sophisticated risk management software such asMonte Carlo Simulation s/w can help you develop models and usesimulations to analyze and respond to various risks. There arealso several s/w packages created specifically for project riskmanagement . If a risk is not identified.

Software should be used as a tool to help make gooddecisions in project risk management, not as a scapegoat for whenthings go wrong.

4.11 SUMMARYCLUSIONS

Risk Management is always forgotten when managingprojects but the irony is that all projects have risk. People in generalthink that risk management is just a blaming session to uncoverflaws in a particular project. This perception has to be abolished.

77

Management and Project managers have to understand thatRisk Management is the one of the few practical way to manageuncertainties and doubts towards a particular project.

Risk can never be abolished, but can only be reduced to anacceptable level. Risk Management is a must for any projects and ithas to be done from the initiation phase throughout the projectlifecycle. Risk Management is not free, and it isn’t cheap. Theremay need to have third party audits which incur cost. There mustalways be continual management support and commitment toensure the success of projects.

This chapter we discussed the importance of riskmanagement in the projects and also were able to understand thedifferent processes in the risk management, which consists of thefollowing actions

� Project risk management is the art and science of identifying,analyzing, and responding to risk throughout the life of a projectand in the best interests of meeting project objectives.

Main processes include: Risk management planning Risk identification Qualitative risk analysis Quantitative risk analysis Risk response planning Risk monitoring and control

Sample Questions1. Discuss the common sources of risk on information technology

projects and suggestions for managing them. (Ans:section 4.4)

2. Explain how to use decision trees and Monte Carlo analysis forquantifying risk. (Ans Hint: section 4.7.1)

Suggested Readings:

1. Boehm ,Barry W. “ Software Risk management: Principles andpractices”

2. Kathy Schwalbe : Information Technology project management

3. Hillson , David. : The risk breakdown structure as an aid toeffective risk management

4. DeMarco,Tom and Timothy Lister: Managing Risk on softwareprojects

4. www.risksig.com

78

5PROJECT PROCUREMENT

MANAGEMENT

Unit Structure:

5.0 Objectives

5.1 Introduction

5.2 Planning Purchases and Acquisitions (Procurement Planning)

5.2.1 Inputs to Procurement Planning

5.2.2 Tools and Techniques for Procurement Planning

5.2.3 Outputs from Procurement Planning

5.3 Solicitation Planning (Planning Contracting)

5.3.1 Tools and Techniques for Solicitation Planning

5.3.2 Outputs from Solicitation Planning

5.4 Requesting Seller Responses (Solicitation)

5.4.1 Inputs to Solicitation

5.4.2 Tools and Techniques for Solicitation

5.4.3 Outputs from Solicitation

5.5 Source Selection (Selecting Sellers)

5.5.1 Inputs to Source Selection

5.5.2 Tools and Techniques for Source Selection

5.5.3 Outputs from Source Selection

5.6 Contract Administration

5.6.1 Inputs to Contract Administration

5.6.2 Suggestions for Change Control in Contracts

5.6.3 Tools and Techniques for Contract Administration

5.6.4 Outputs from Contract Administration

5.7 Contract Close-Out

5.7.1 Inputs to Contract Close-out

5.7.2 Tools and Techniques for Contract Close-out

5.7.3 Outputs from Contract Close-out

5.8 Using Software to Assist in Project Procurement Management

5.9 Out Sourcing

5.9.1 Benefits of outsourcing

5.10 Summary

79

5.0 OBJECTIVES

To understand the importance of project procurementManagement

To describe project procurement management processes

Procurement planning

Solicitation planning

Solicitation

Source selection

Contract administration

Contract close-out

5.1 INTRODUCTION

Project Procurement Management includes the processesrequired to acquire goods and services from outside the performingorganization. For simplicity, goods and services, whether one ormany, will generally be referred to as a “product.” Figure 5.1provides an overview of the following major processes:

5.2 Procurement Planning—determining what to procure andwhen.

5.3 Solicitation Planning—documenting product requirements andidentifying potential sources.

5.4 Solicitation—obtaining quotations, bids, offers, or proposalsas appropriate.

5.5 Source Selection—choosing from among potential sellers.

5.6 Contract Administration—managing the relationship with theseller.

5.7 Contract Close-out—completion and settlement of thecontract, including resolution of any open items.

These processes interact with each other and with theprocesses in the other knowledge areas as well. Each process mayinvolve effort from one or more individuals or groups of individualsbased on the needs of the project. Although the processes arepresented here as discrete elements with well-defined interfaces, inpractice they may overlap and interact in ways not detailed here.

80

Project Procurement Management is discussed from theperspective of the buyer in the buyer-seller relationship. The buyer-seller relationship can exist at many levels on one project.Depending on the application area, the seller may be called acontractor, a vendor, or a supplier.

The seller will typically manage their work as a project. In suchcases:

• The buyer becomes the customer and is thus a key stakeholderfor the seller.

• The seller’s project management team must be concerned with allthe processes of project management, not just with those of thisknowledge area.

• The terms and conditions of the contract become a key input tomany of the seller’s processes. The contract may actually containthe input (e.g., major deliverables, key milestones, costobjectives) or it may limit the project team’s options (e.g., buyerapproval of staffing decisions is often required on designprojects).

This chapter assumes that the seller is external to theperforming organization.

Most of the discussion, however, is equally applicable toformal agreements entered into with other units of the performingorganization. When informal agreements are involved, theprocesses described in Project Human Resource Management,,and Project Communications Management, are more likelyto apply.

81

Figure 5.1

5.2 PLANNING PURCHASES AND ACQUISITIONS(PROCUREMENT PLANNING)

Procurement planning is the process of identifying whichproject needs can be best met by procuring products or servicesoutside the project organization. It involves consideration ofwhether to procure, how to procure, what to procure, how much toprocure, and when to procure it.

When the project obtains products and services from outsidethe performing organization, the processes from solicitation

82

planning through contract close-out would be performed once foreach product or service item.

The project management team should seek support fromspecialists in the disciplines of contracting and procurement whenneeded.

When the project does not obtain products and services fromoutside the performing organization, the processes from solicitationplanning through contract close-out would not be performed. Thisoften occurs on research and development projects when theperforming organization is reluctant to share project technology,and on many smaller, in-house projects when the cost of findingand managing an external resource may exceed the potentialsavings.

Procurement planning should also include consideration ofpotential subcontracts, particularly if the buyer wishes to exercisesome degree of influence or control over subcontracting decisions.

Steps in procurement planning

5.2.1 Inputs to Procurement Planning:

1 Scope statement: The scope statement describes the currentproject boundaries. It provides important information about projectneeds and strategies that must be considered during procurementplanning.

2 Product description: The description of the product of theproject provides important information about any technical issues orconcerns that would need to be considered during procurementplanning.

The product description is generally broader than astatement of work. A product description describes the ultimateend-product of the project; a statement of work describes theportion of that product to be provided by a seller to the project.However, if the performing organization chooses to procure the

83

entire product, the distinction between the two terms becomesmoot.

3 Procurement resources: If the performing organization does nothave a formal contracting group, the project team will have tosupply both the resources and the expertise to support projectprocurement activities.

4 Market conditions: The procurement planning process mustconsider what products and services are available in themarketplace, from whom, and under what terms and conditions.

5 Other planning outputs: To the extent that other planningoutputs are available, they must be considered during procurementplanning. Other planning outputs which must often be consideredinclude preliminary cost and schedule estimates, qualitymanagement plans, cash flow projections, the work breakdownstructure, identified risks, and planned staffing.

6 Constraints: Constraints are factors that limit the buyer’soptions. One of the most common constraints for many projects isfunds availability.

7 Assumptions: Assumptions are factors that, for planningpurposes, will be consideredto be true, real, or certain.

5.2.2 Tools and Techniques for Procurement Planning:

1. Make-or-buy analysis: This is a general management techniquewhich can be used to determine whether a particular product canbe produced cost-effectively by the performing organization. Bothsides of the analysis include indirect as well as direct costs. Forexample, the “buy” side of the analysis should include both theactual out of- pocket cost to purchase the product as well as theindirect costs of managing the purchasing process.

A make-or-buy analysis must also reflect the perspective ofthe performing organization as well as the immediate needs of theproject. For example, purchasing a capital item (anything from aconstruction crane to a personal computer) rather than renting it isseldom cost effective. However, if the performing organization hasan ongoing need for the item, the portion of the purchase costallocated to the project may be less than the cost of the rental.

Make-or-Buy Example:

� Assume you can lease an item you need for a project for$150/day. To purchase the item, the cost is $1,000 plus a dailyoperational cost of $50/day.

84

� How long will it take for the purchase cost to be the same as thelease cost?� If you need the item for 12 days, should you lease it or purchaseit?

Make-or Buy Solution:

Set up an equation so the “make” is equal to the “buy”

In this example, use the following equation. Let d be thenumber of days to use the item.

$150d = $1,000 + $50d

Solve for d as follows:

Subtract $50d from the right side of the equation to get

$100d = $1,000

Divide both sides of the equation by $100

d = 10 days

The lease cost is the same as the purchase cost at 10 days

If you need the item for 12 days, it would be moreeconomical to

purchase it

2 Expert judgment: Expert judgment will often be required toassess the inputs to this process. Such expertise may be providedby any group or individual with specialized knowledge or trainingand is available from many sources including:

Other units within the performing organization. Consultants. Professional and technical associations. Industry groups.

3 Contract type selection: Different types of contracts are more orless appropriate for different types of purchases. Contractsgenerally fall into one of three broad categories:

Fixed price or lump sum contracts—this category of contractinvolves a fixed total price for a well-defined product. To theextent that the product is not well-defined, both the buyerand seller are at risk—the buyer may not receive the desiredproduct or the seller may need to incur additional costs inorder to provide it. Fixed price contracts may also includeincentives for meeting or exceeding selected projectobjectives such as schedule targets.

85

Cost reimbursable contracts—this category of contractinvolves payment (reimbursement) to the seller for its actualcosts. Costs are usually classified as direct costs or indirectcosts. Direct costs are costs incurred for the exclusivebenefit of the project (e.g., salaries of full-time project staff).Indirect costs, also called overhead costs, are costsallocated to the project by the performing organization as acost of doing business (e.g., salaries of corporateexecutives). Indirect costs are usually calculated as apercentage of direct costs. Cost reimbursable contractsoften include incentives for meeting or exceeding selectedproject objectives such as schedule targets or total cost.

Three types of cost reimbursable contracts in order of lowestto highest risk to the buyer include cost plus incentive fee, costplus fixed fee, and cost plus percentage of costs With a cost plusincentive fee (CPIF) contract the buyer pays the supplier forallowable performance cost along with a predetermined fee and anincentive bonus.if the final Cost is less than the expected cost,both the buyer and the supplier benefit from the cost saving.

With a cost plus fixed fee (CPFF) contract the buyer paysthe supplier for the allowable performance cost plus a fixed feepayment usually based on a percentage of estimated costs.

With a cost plus percentage of costs(CPPC) contract thebuyer pays the supplier for allowable performance costs along witha predetermined percentage based on the total costs.

Unit price contracts—the seller is paid a preset amount perunit of service (e.g., $70 per hour for professional servicesor $1.08 per cubic yard of earth removed), and the totalvalue of the contract is a function of the quantities needed tocomplete the work.

Contract Types Versus Risk

86

5.2.3 Outputs from Procurement Planning:

1. Procurement management plan. The procurementmanagement plan should describe how the remaining procurementprocesses (from solicitation planning through contract close-out)will be managed. For example:

• What types of contracts will be used?

• If independent estimates will be needed as evaluation criteria,who will prepare them and when?

• If the performing organization has a procurement department,what actions can the project management team take on its own?

• If standardized procurement documents are needed, where canthey be found?

• How will multiple providers be managed?

• How will procurement be coordinated with other project aspectssuch as scheduling and performance reporting?

A procurement management plan may be formal or informal,highly detailed or broadly framed, based on the needs of theproject. It is a subsidiary element of the overall project plan.

2 Statement(s) of work: The statement of work (SOW) describesthe procurement item in sufficient detail to allow prospective sellersto determine if they are capable of providing the item. “Sufficientdetail” may vary based on the nature of the item, the needs of thebuyer, or the expected contract form.

Some application areas recognize different types of SOW.For example, in some government jurisdictions, the term SOW isreserved for a procurement item that is a clearly specified productor service, and the term Statement of Requirements (SOR) is usedfor a procurement item that is presented as a problem to be solved.The statement of work may be revised and refined as it movesthrough the procurement process. For example, a prospectiveseller may suggest a more efficient approach or a less costlyproduct than that originally specified. Each individual procurementitem requires a separate statement of work. However, multipleproducts or services may be grouped as one procurement item witha single SOW.

The statement of work should be as clear, as complete, andas concise as possible.

It should include a description of any collateral servicesrequired, such as performance reporting or post-project operationalsupport for the procured item. In some application areas, there are

87

specific content and format requirements for a SOW. The followingfigure shows a template of statement of work.

Statement of Work (SOW) Template

5.3 SOLICITATION PLANNING (PLANNINGCONTRACTING)

Solicitation planning involves preparing the documents needed tosupport solicitation.

Steps in solicitation planning

5.3.1 Tools and Techniques for Solicitation Planning:

1. Standard forms: Standard forms may include standardcontracts, standard descriptions of procurement items, or

88

standardized versions of all or part of the needed bid documents.Organizations that do substantial amounts of procurement shouldhave many of these documents standardized.

2. Expert judgment: Expert judgment is described inSection 5.2.2.

5.3.2 Outputs from Solicitation Planning:

1. Procurement documents: Procurement documents are used tosolicit proposals from prospective sellers. The terms “bid” and“quotation” are generally used when the source selection decisionwill be price-driven (as when buying commercial items), while theterm “proposal” is generally used when non-financial considerationssuch as technical skills or approach are paramount (as whenbuying professional services).

However, the terms are often used interchangeably and careshould be taken not to make unwarranted assumptions about theimplications of the term used.

Common names for different types of procurementdocuments include: Invitation for bid (IFB), Request for Proposal(RFP), Request for Quotation (RFQ), Invitation for Negotiation, andContractor Initial Response.

Procurement documents should be structured to facilitateaccurate and complete responses from prospective sellers. Theyshould always include the relevant statement of work, a descriptionof the desired form of the response, and any required contractualprovisions (e.g., a copy of a model contract, non-disclosureprovisions).

Some or all of the content and structure of procurementdocuments, particularly for those prepared by a governmentagency, may be defined by regulation.

Procurement documents should be rigorous enough toensure consistent, comparable responses, but flexible enough toallow consideration of seller suggestions for better ways to satisfythe requirements. The following figure shows a template for RFP

Request For proposal Template

I. Purpose of RFPII. Organization’s BackgroundIII. Basic RequirementsIV. Hardware and Software EnvironmentV. Description of RFP ProcessVI. Statement of Work and Schedule InformationVII. Possible Appendices

89

A. Current System OverviewB. System RequirementsC. Volume and Size DataD. Required Contents of Vendor’s Response to RFPE. Sample Contract

2. Evaluation criteria. Evaluation criteria are used to rate or scoreproposals. They may be objective (e.g., “the proposed projectmanager must be a certified Project Management Professional”) orsubjective (e.g., “the proposed project manager must havedocumented, previous experience with similar projects”). Evaluationcriteria are often included as part of the procurement documents.

Evaluation criteria may be limited to purchase price if theprocurement item is known to be readily available from a number ofacceptable sources (“purchase price” in this context includes boththe cost of the item and ancillary expenses such as delivery). Whenthis is not the case, other criteria must be identified anddocumented to support an integrated assessment. For example:

• Understanding of need—as demonstrated by the seller’s proposal.

• Overall or life cycle cost—will the selected seller produce thelowest total cost (purchase cost plus operating cost)?

• Technical capability—does the seller have, or can the seller bereasonably expected to acquire, the technical skills andknowledge needed?

3. Statement of work updates. The statement of work is describedin Section 12.1.3.2.

Modifications to one or more statements of work may be identifiedduring solicitation planning.

5.4 REQUESTING SELLER RESPONSES(SOLICITATION)

Solicitation involves obtaining information (bids andproposals) from prospective sellers on how project needs can bemet. Most of the actual effort in this process is expended by theprospective sellers, normally at no cost to the project.

90

Steps in solicitation

5.4.1 Inputs to Solicitation:

1. Procurement documents: Procurement documents aredescribed in previous section.

2. Qualified seller lists: Some organizations maintain lists or fileswith information on prospective sellers. These lists will generallyhave information on relevant experience and other characteristicsof the prospective sellers.

If such lists are not readily available, the project team willhave to develop its own sources. General information is widelyavailable through library directories, relevant local associations,trade catalogs, and similar sources. Detailed information on specificsources may require more extensive effort, such as site visits orcontact with previous customers.

Procurement documents may be sent to some or all of theprospective sellers.

5.4.2 Tools and Techniques for Solicitation:

1. Bidder conferences: Bidder conferences (also calledcontractor conferences, vendor conferences, and pre-bidconferences) are meetings with prospective sellers prior topreparation of a proposal. They are used to ensure that allprospective sellers have a clear, common understanding of theprocurement (technical requirements, contract requirements, etc.).Responses to questions may be incorporated into the procurementdocuments as amendments.

2. Advertising: Existing lists of potential sellers can often beexpanded by placing advertisements in general circulationpublications such as newspapers or in specialty publications suchas professional journals. Some government jurisdictions requirepublic advertising of certain types of procurement items; most

91

government jurisdictions require public advertising of subcontractson a government contract.

5.4.3 Outputs from Solicitation:

1. Proposals: Proposals are seller-prepared documents thatdescribe the seller’s ability and willingness to provide the requestedproduct. They are prepared in accordance with the requirements ofthe relevant procurement documents.

5.5 SOURCE SELECTION (SELECTINGSELLERS)

Source selection involves:

Evaluating proposals or bids from sellers.

Choosing the best one.

Negotiating the contract.

Awarding the contract.

Organizations often do an initial evaluation of all proposalsand bids and then develop a short list of potential sellersfor further evaluation.

Source selection involves the receipt of bids or proposalsand the application of the evaluation criteria to select a provider.This process is seldom straightforward:

• Price may be the primary determinant for an off-the-shelf item, butthe lowest proposed price may not be the lowest cost if the sellerproves unable to deliver the product in a timely manner.

• Proposals are often separated into technical (approach) andcommercial (price) sections with each evaluated separately.

• Multiple sources may be required for critical products.

The tools and techniques described below may be usedsingly or in combination.

For example, a weighting system may be used to:• Select a single source who will be asked to sign a standard

contract.• Rank order all proposals to establish a negotiating sequence.

On major procurement items, this process may be iterated. Ashort list of qualified sellers will be selected based on a preliminary

92

proposal, and then a more detailed evaluation will be conductedbased on a more detailed and comprehensive proposal.

Steps in source selection

5.5.1 Inputs to Source Selection:

1. Proposals. Proposals are described in Section 5.2.2.

2. Evaluation criteria. Evaluation criteria are described in Section5.2.2(2)

3. Organizational policies. Any and all of the organizationsinvolved in the project may have formal or informal policies that canaffect the evaluation of proposals.

5.5.2 Tools and Techniques for Source Selection:

1. Contract negotiation: Contract negotiation involves clarificationand mutual agreement on the structure and requirements of thecontract prior to the signing of the contract. To the extent possible,final contract language should reflect all agreements reached.Subjects covered generally include, but are not limited to,responsibilities and authorities, applicable terms and law, technicaland business management approaches, contract financing, andprice.

For complex procurement items, contract negotiation may bean independent process with inputs (e.g., an issues or open itemslist) and outputs (e.g., memorandum of understanding) of its own.Contract negotiation is a special case of the general managementskill called “negotiation.”

Negotiation tools, techniques, and styles are widelydiscussed in the general management literature and are generallyapplicable to contract negotiation.

93

2. Weighting system: A weighting system is a method forquantifying qualitative data in order to minimize the effect ofpersonal prejudice on source selection. Most such systems involve(1) assigning a numerical weight to each of the evaluation criteria,(2) rating the prospective sellers on each criterion, (3) multiplyingthe weight by the rating, and (4) totaling the resultant products tocompute an overall score.

3. Screening system: A screening system involves establishingminimum requirements of performance for one or more of theevaluation criteria. For example, a prospective seller might berequired to propose a project manager who is a ProjectManagement Professional (PMP) before the remainder of theirproposal would be considered.

4 Independent estimates: For many procurement items, theprocuring organization may prepare its own estimates as a checkon proposed pricing. Significant differences from these estimatesmay be an indication that the SOW was not adequate or that theprospective seller either misunderstood or failed to respond fully tothe SOW. Independent estimates are often referred to as “shouldcost” estimates.

5.5.3 Outputs from Source Selection:

1.Contract: A contract is a mutually binding agreement whichobligates the seller to provide the specified product and obligatesthe buyer to pay for it. A contract is a legal relationship subject toremedy in the courts. The agreement may be simple or complex,usually (but not always) reflecting the simplicity or complexity of theproduct. It may be called, among other names, a contract, anagreement, a subcontract, a purchase order, or a memorandum ofunderstanding

5.6 CONTRACT ADMINISTRATION

Contract administration is the process of ensuring that theseller’s performance meets contractual requirements. On largerprojects with multiple product and service providers, a key aspect ofcontract administration is managing the interfaces among thevarious providers. The legal nature of the contractual relationshipmakes it imperative that the project team be acutely aware of thelegal implications of actions taken when administering the contract.

Contract administration includes application of theappropriate project management processes to the contractualrelationship(s) and integration of the outputs from these processesinto the overall management of the project. This integration and

94

coordination will often occur at multiple levels when there aremultiple sellers and multiple products involved. The projectmanagement processes which must be applied include:

• Project plan execution, authorize the contractor’s work at theappropriate time.

• Performance reporting, is, to monitor contractor cost, schedule,and technical performance.

• Quality control, is to inspect and verify the adequacy of thecontractor’s product.

• Change control, is , to ensure that changes are properly approvedand that all those with a need to know are aware of suchchanges.

5.6.1 Inputs to Contract Administration:

1. Contract. Contracts are described in previous Section

2. Work results. The seller’s work results—which deliverableshave been completed and which have not, to what extent arequality standards being met, what costs have been incurred orcommitted, etc.—are collected as part of project plan execution

3. Change requests. Change requests may include modificationsto the terms of the contract or to the description of the product orservice to be provided. If the seller’s work is unsatisfactory, adecision to terminate the contract would also be handled as achange request. Contested changes, those where the seller andthe project management team cannot agree on compensation forthe change, are variously called claims, disputes, or appeals.

4. Seller invoices. The seller must submit invoices from time totime to request payment for work performed. Invoicingrequirements, including necessary supporting documentation, areusually defined in the contract.

5.6.2 Suggestions for Change Control in Contracts:

Changes to any part of the project need to be reviewed,approved, and documented by the same people in the sameway 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 qualityof the goods or services being provided?

Changes must be documented in writing. Project teammembers should also document all important meetings andtelephone phone calls.

95

Project managers and teams should stay closely involved tomake sure the new system will meet business needs andwork in an operational environment.

Have backup plans.

Use tools and techniques, such as a contract changecontrol system, buyer conducted performance reviews,inspections and audits, and so on.

Contract administration also has a financial managementcomponent. Payment terms should be defined within the contractand should involve a specific linkage between progress made andcompensation paid.

5.6.3 Tools and Techniques for Contract Administration”

1. Contract change control system: A contract change controlsystem defines the process by which the contract may be modified.It includes the paperwork, tracking systems, dispute resolutionprocedures, and approval levels necessary for authorizing changes.The contract change control system should be integrated with theoverall change control system .

2. Performance reporting: Performance reporting providesmanagement with information about how effectively the seller isachieving the contractual objectives. Contract performancereporting should be integrated with the overall project performancereporting.

3. Payment system: Payments to the seller are usually handled bythe accounts payable system of the performing organization. Onlarger projects with many or complex procurement requirements,the project may develop its own system. In either case, the systemmust include appropriate reviews and approvals by the projectmanagement team.

5.6.4 Outputs from Contract Administration:

1. Correspondence: Contract terms and conditions often requirewritten documentation of certain aspects of buyer/sellercommunications, such as warnings of unsatisfactory performanceand contract changes or clarifications.

2. Contract changes: Changes (approved and unapproved) arefed back through the appropriate project planning and projectprocurement processes, and the project plan or other relevantdocumentation is updated as appropriate.

96

3. Payment requests: This assumes that the project is using anexternal payment system. If the project has its own internal system,the output here would simply be “payments.”

5.7 CONTRACT CLOSE-OUT

Contract close-out is similar to administrative closure in thatit involves both product verification (Was all work completedcorrectly and satisfactorily?) and administrative close-out (updatingof records to reflect final results and archiving of such informationfor future use). The contract terms and conditions may prescribespecific procedures for contract close-out. Early termination of acontract is a special case of contract close-out.

5.7.1 Inputs to Contract Close-out:

Contract documentation: Contract documentation includes, but isnot limited to, the contract itself along with all supporting schedules,requested and approved contract changes, any seller-developedtechnical documentation, seller performance reports, financialdocuments such as invoices and payment records, and the resultsof any contract-related inspections.

5.7.2 Tools and Techniques for Contract Close-out:

Procurement audits: A procurement audit is a structured review ofthe procurement process from procurement planning throughcontract administration. The objective of a procurement audit is toidentify successes and failures that warrant transfer to otherprocurement items on this project or to other projects within theperforming organization.

5.7.3 Outputs from Contract Close-out:

1 Contract file: A complete set of indexed records should beprepared for inclusion with the final project records.

2 Formal acceptance and closure: The person or organizationresponsible for contract administration should provide the sellerwith formal written notice that the contract has been completed.Requirements for formal acceptance and closure are usuallydefined in the contract.

5.8 USING SOFTWARE TO ASSIST IN PROJECTPROCUREMENT MANAGEMENT

Word processing software helps write proposals andcontracts, spreadsheets help evaluate suppliers, databases help

97

track suppliers, and presentation software helps presentprocurement-related information. E-procurement software doesmany procurement functions electronically. Organizations also useother Internet tools to find information on suppliers or auction goodsand services.

Established companies such as Oracle ,SAS, and Baanhave developed new software products to assist in procurementmanagement .As with information or software tool, organizationmust focus on using the information and tools to meet the projectand organizational needs. Organizations should often developpartnerships and strategic alliances with other organizations to takeadvantage of potential cost savings.

5.9 OUT SOURCING

Outsourcing software development and other informationtechnology, or I.T. services continues to grow in popularity. Thereare several important reasons for this. Many companies that havenot traditionally considered outsourcing may be surprised to learnof the benefits that it could bring them. Even organizations withlarge software teams may be candidates for outsourcing some oftheir projects.

5.9.1 Benefits of outsourcing To allow the client organization to focus on its core business To access skills and technologies To reduce both fixed and recurrent costs To provide flexibility To increase accountability

Information technology is rapidly becoming more complexand is constantly changing. At the same time, many companies arefinding that they increasingly need to focus their attention on theareas of their strength due to rapidly increasing market competition.For many of these companies, outsourcing I.T., at least projectsthat are outside their area of expertise, can greatly strengthen theircompetitive advantage. It also brings new energy to theorganization to have projects that were causing ongoing frustration,cost, and risk to now be in the hands of another organization withthe specialized skills and experience needed.

Organizations that only have budget to hire a few individualsoften find that by outsourcing their projects, they are still able toobtain access to a wide range of high level skills. Outsourceddevelopment companies can apply the best skill for each phase ofa project. This flexibility and the availability of a larger talent poolprovides optimum results at the lowest cost.

98

Selecting the right outsourcing partner is key to realizingthese benefits. Selecting an organization of an appropriate size isimportant. An organization that is too large for your project bringsunnecessary costs and overhead. Selecting an organization withthe appropriate level of skills is also important. For projects thatprovide significant business value and which you expect to be usedlong term, it is important to select an organization whose peoplehave true enterprise level experience. The organization's vision,high-level design skills, and ability to understand and support yourbusiness goals are also very important. This is often the greatestchallenge with outsourcing overseas. It takes more than technicalskills for project success. The ideal outsource organization willprovide local individuals with these skills as well as overseas teamsthat they have established relationships with.

This can provide small outsourced projects with theadvantage of international cost savings combined with the ease ofmanagement and all the other potential advantages thatoutsourcing has to offer.

Outsourcing can provide tremendous benefit toorganizations. It can reduce complexity and cost while increasingproject success. Selecting an organization with the necessary levelof skills and experience locally and who have their own establishedinternational team provides an ideal formula for success. Together,this provides your organization with the maximum efficiency andeffectiveness.

5.10 SUMMARY

Project procurement management involves acquiring goodsand services for a project from outside the performing organization.Procurement, purchasing or outsourcing is acquiring goods orservices from outside source. Organizations outsource to reducecosts, focus on their core business access skills and technologies,provide flexibility and increase accountability. In this chapter wecould discuss the various steps involved in the procurementmanagement process needed for a project.

Processes include: Planning purchases and acquisitions Planning contracting Requesting seller responses Selecting sellers Administering contracts Closing contracts

99

Sample questions1. What is involved in the process of requesting seller

responses?. How do organizations decide whom to sendRFPs or RFQs?.(ANS: See section 5.3)

2. Explain the make or buy decision process and describe howto perform the financial calculations involved in the lease orbuy example.(ANS: See section 5.1.2)

Suggested Readings.

1. Flemming, Quentin: Project procurement management ,contracting, subcontracting ,teaming.

2. Kathy Schwalbe : Information Technology project management

3. Jack T.Marchewka: Information Technology project management

4. www. Informationweek.com

5. www.cio.com

100

6

CHANGE MANAGEMENT

Unit Structure:

6.0 Objectives

6.1 Introduction

6.2 The Nature of Change

6.2.1 The ADKAR Model

6.2.2 Change is a process

6.2.3 Change can be emotional

6.3 Change Management Plan

6.3.1 Develop a Strategy for Change

6.3.2Implement Change Management Plan and Trackprogress

6.4 Dealing with resistance and Conflict

6.4.1 Polarity Management

6.5 Summary

6.0 OBJECTIVES

After reading this chapter, you will be able to

Describe the ADKAR model for change managementallowing change management teams to focus their activitieson specific business results.

Describe creating change within an organization takes hardwork and structure around what must actually take place tomake the change happen.

Implement control change, through change approvals andreviews

Define the standardized methods and procedures are usedfor efficient and prompt handling of all changes to controlledIT infrastructure.

To develop a change management plan. The plan focus onassessing organization’s willingness and ability to change,

101

developing a change strategy and evaluating whether thechange was successful or not.

Discuss the nature of resistance and conflict and applytechniques for dealing with resistance and conflict.

6.1 INTRODUCTION

``TO IMPROVE is to change, to be perfect is to change often"-Winston Churchill

Nothing can better emphasize the need for change. Everyorganization needs to change with time; failing which, it stands therisk of being pushed into oblivion and being labeled as obsolete bythe more enterprising competitors in the market.

Change management enables planning, controlling andcoordinating all changes to an IT environment using standardizedmethods and procedures. Maximize process efficiency. Minimizechange risk. Information Technology projects are plannedorganizational change. An IT project has an impact on theorganization and organization has an impact on the IT projects.

The change you must, at the needed intervals. Changecould be effected in the overall policy and procedure, in theinfrastructure, in the structuring of staff, etc To implementsuccessful change, as a manager, you need an overall leadershipforce that is greater than the combined force of resistance. Byunderstanding the most common ways that people respond tochange and learning how to convince the ones who are resistant tochange, you can overcome these types of problems in theorganization. (ASPM O’reilly)

According to Leslie Jaye Goff, the change management isabout helping people deal with their emotions. IT professionalsshould be willing to put themselves in their user’s shoes in order tounderstand how change will affect them.

The central theme of this chapter has been the concept ofmeasurable organization value. The project’s MOV provides ameans for determining which project should be funded and drivesmany of the decisions.

6.2 THE NATURE OF CHANGE

This section focus on the ADKAR result-oriented model ofchange management, impact of change that allows changemanagement teams to focus their activities on specific business

102

results. To understand impact of change, change is a process andthe emotional behavior of change.6.2.1 The ADKAR model – a model for change management:

The ADKAR change model was first published by Prosci in1998, an independent research company specializing in the areasof change management, business process reengineering, theydeveloped the ADKAR model. The model was initially used as atool for determining if change management activities likecommunications and training were having the desired results duringorganizational change.

Change management, a critical component of business, canbe achieved successfully using the ADKAR procedure. Changeoften brings high levels of stress and agitation to people. It is usedas a resistance management tool, an assessment device and tohelp change management teams organize their work. This model, ifapplied completely, should result in a successful transition fromformer procedures to new procedures without fail or regardless ofthe complexity of the change.

The five key goals as shown in figure 7.1 form the basis ofthe ADKAR model.

Awareness - making employees at every level understand whychange is necessary. They must understand that change does notcome from the desire to do things differently but in order to improveon business activities and stay ahead of your competition, and/orincrease the bottom line, is not only wise, but also necessary forsuccess.E.g., Customer input, Market changes etc.,

Desire: After making employees aware about the change, the nextstep will be making them have the desire to support and activelyparticipate in the forthcoming changes.E.g., fear of job loss, incentive or compensation, careeradvancement.

Knowledge: Management must provide the training and educationto its staff of the methods of changing to the new procedures, ororganization. High levels of awareness and desire will proveuseless if they lack the necessary knowledge of how to change toaccomplish the goals.E.g., training and education, examples and role models.

Ability: Along with the knowledge of how to affect successfulchange, everyone involved needs to be given the specific trainingand information to achieve success in implementing the details ofthe changes to be made.

103

E.g., Practice applying new skills, mentoring and so on.

Reinforcement: to retain the change once it has been made,reinforcing the new “habits” of the staff typically improve thesuccess of the changes made.E.g., Personal recognition, celebrations.

An organization's culture, history, values and capacity forchange are potential obstacles for change management teams.Consultants and change management teams often address thesepotential barriers with assessments. This relatively simple, logicalmethod of implementing change management has proven to workwell. It is not surprising or mysterious. This model, if appliedcompletely, should result in a successful transition from formerprocedures to new procedures without fail or regardless of thecomplexity of the change.

Figure 6.1

6.2.2 Change is a process:

Kurt Lewin emigrated from Germany to America during the1930's. Lewin is recognized as the "founder of social psychology"which immediately points to his interest in the human aspect ofchange. Lewin's change management model is linked to force fieldanalysis. Force field analysis is used extensively for purposes oforganizational and human resource development, to help indicatewhen driving and restraining forces are not in balance, so thatchange can occur.

104

Lewin proposed a three stage basic theory of changeincludes Unfreeze, Change, Freeze (or Refreeze) as shown indiagram. The present state represents equilibrium, to change fromthe current state; there must be driving forces both to initiate and tomotivate the change.

Figure 6.2 depicts a transition from present state to thedesired state, it is also referred as neutral zone. Problems arisewhen managers do not understand, expect the neutral zone.

Stage 1 – becoming motivated to change (unfreezing)

This phase of change is built on the theory that humanbehavior is established by past observational learning and culturalinfluences that human behavior is established by past observationallearning and cultural influences. Change requires adding newforces for change or removal of some of the existing factors that areat play in perpetuating the behavior.

Stage 2 – change what needs to be changed (unfrozen and movingto a new state)

Once there is sufficient dissatisfaction with the currentconditions and a real desire to make some change exists, it isnecessary to identify exactly what needs to be changed. A conciseview of the new state is required to clearly identify the gap betweenthe present state and that being proposed. Activities that aid inmaking the change include imitation of role models and looking forpersonalized solutions through trial-and-error learning.

Stage 3 – making the change permanent (refreezing)

Refreezing is the final stage where new behavior becomeshabitual, which includes developing a new self-concept & identityand establishing new interpersonal relationships.

Figure 6.2

105

6.2.3 Change can be Emotional:

Change can also bring out emotional responses. Anindividual may have an emotional response to a change when thechange is perceived as a loss a well-established equilibrium. In thebook On Death and Dying author Elizabeth Kubler-Ross providesdepicts the emotions.

The model has five stages, if people are not allowed to sufferand go through the first four stages, then going to fifth stage isextremely difficult. The human being we have a mechanism we douse grief counselors to varying extent in our day to day life. If we aschange agents know this we can make sure that people we doexperience some of these stage have information readily availableto enable to progress. The Kubler-Ross model is a useful forunderstanding people's emotional reaction to personal trauma andchange, irrespective of cause. The six stages include:

Immobilization: The initial reaction to the announcement of thechange is shock. The change is so alien to the participant’sframe of reference that he or she is often unable to relate whatis happening, resulting in temporary confusion or completedisorientation.

Denial – It is a conscious or unconscious refusal to acceptfacts, information, reality, etc., relating to the situationconcerned. For e.g., when a person is informed that she isbeing fired by organization, the initial response may be, Are youserious?

Anger – The anger is a more active emotional response.People dealing with emotional upset can be angry withthemselves, and/or with others, especially those close to them.There is a difference between feeling anger and acting out inanger.

Bargaining – In this stage the person may be cooperative andmay try to make deals to avoid change. People facing lessserious trauma can bargain or seek to negotiate a compromise.For e.g., the person who is fired from the organization maypromise the management that she will take a cut in pay to avoidbeing let go.

Depression – It is also referred to as preparatory grieving. Thisstage occurs when there is an overwhelming sense of the lossof the status escape. It's a sort of acceptance with emotionalattachment and also it shows that the person has at least begunto accept the reality.

106

Acceptance – This stage varies according to the person'ssituation, in this stage a person comes to grips with the change.Acceptance is an important part of ending the status escapeand getting on with a new state.

6.3 THE CHANGE MANAGEMENT PLAN

Change Management doesn't need to be "just another thingon your project management checklist." Instead, use the changemanagement methodology to guide how you deal with change inyour projects. Often, just having a set of rules by which you and allinvolved team members and stakeholders can follow makes iteasier for you to deal with the change that will inevitably crop up inyour projects. This way, you can focus more energy on planningand monitoring and less energy on fighting fires.

Once the change management plan has been developed itshould be integrated with the project plan and can be included atany point after start up. Figure 7.3 provides a framework fordeveloping a change management plan.

Figure 6.3

107

Ready, Willing, and Able to Change:

This is the first step for developing a change managementplan that is to assess the organization’s readiness, willingness andability to change. This assessment defines several roles involved ina change management – the sponsor, change agents, changeadvocate and targets.

Sponsor A sponsor is the individual (or group) with thepower to determine that change will occur. This person or group ofproject sponsor, an initiating sponsor has the authority to makeresources available and support the project, then this person mayhandoff the project to a sustaining sponsor. A major portion of theorganization’s ability and willingness to support the change restswith the sponsor’s commitment to the project. If the project failsbecause the organization cannot adapt to the change, the project’senvisioned value to the organization is lost and the sponsor’scredibility is reduced.

Change Agents An agent is the individual (or group)responsible for seeing that a previously determined change occursto achieve project’s goals. They design and implement or help toimplement the change. Change agents report to the sponsor andmust diagnose problems, plan to deal with these issues. The abilityto sustain the change with the IT projects rests with the changeagents.

Change Advocate An advocate is the individual (or group)who want to achieve a change but lacks the power to sanction itand require support from the appropriate sponsor who can approvethe change. Any individual within an organization who has a goodidea and the ability to communicate it can be a change advocate.

Targets A target is the individual or group that must change.They may be the users of the new system or those will be directlyinvolved with final product of the project. The dynamics associatedwith the targets of change become most critical for supporting andcarrying out the change effort.

Leavitt suggests that the effectiveness of any changeprogram can only be achieved through a balance of fourorganizational subsystems: technology, structure, tasks andpeople. The model shown in Figure 7.4 illustrates how all four ofthese items are interrelated.

108

Figure 7.4

Structure - levels of hierarchy, spans of authority, centralization.

Technology - complexity, degree of employee usage, operatorcontrol & responsibility.

People - values, beliefs, attitudes, motives, drives, competencies.

Task - job design, repetitiveness, physical & cognitive demands,autonomy & discretion.

Change at any one point will impact some or all of theothers. Thus, a changed task will necessarily affect the peopleinvolved in it, the structure in which they work, and the technologythat they use. Failure to manage these interdependencies at criticaltimes of change can create problems.

As a result of the planned change, people will go through avariety of emotions. So it is important that a boundary be defined ina way that allows the change to happen as planned, but also allowsindividual “to take something with them” by giving somethingfamiliar to hold on to so as to ease the transition. This allows thepast to be remembered with reverence and can also mark the endand the new beginning.

Leavitt's Model of Change: Task,Technology, Structure, and People

People

Task

Technology

Structure

109

People become confused and disoriented when the rules forsuccess change are no longer clearly defined. Lets say that youhave been working at a company for several years. Over that time,you have become part of that culture and you know that, in ourcompany promotions is based on seniority and the layoff’s willbegin with the employees with the least seniority. What if thecompany you work for has been acquired by some otherorganization? The acquiring company has decided to make a fewchanges and start downsizing the workforce in your company andonly top performance will be invited to stay. The rules for successhave changed.

6.3.1 Develop a Strategy for Change:

The developing a strategy for change is the step after thechange is assessed. Davidson provides four approaches to changemanagement.

Rational-Empirical Approach

The Rational-Empirical strategy suggests that most peopleare rational, so they will accept change that will benefit the overallorganization. People are rational beings and will follow their self-interest once it is revealed to them.

It is important that the individuals affected by the change beprovided with consistent and timely information. Mixed messagescan lead to confusion and suspicion. When people are not givenenough information, they tend to seek information from othersources; these messages might be rely on suggestions,misinformation and opinions. Successful change is based on thecommunication of information and the proffering of incentives.

The change management plan based on this strategy shouldprovide each individual with the purpose, a picture and a part toplay. Often individuals within organization have a narrow view oftheir job and its relationship to the rest of the organization. It maybe useful to provide people with a chance to experience theproblem or opportunity first-hand. A picture provides a vision in theindividual’s mind as to how the organization will look or operate inthe future. If done effectively, this procedure can help the individualbuy into the proposed change. A part can be effective in helping theindividual become involved in the proposed change. It is importantfor the individual to understand and visualize the part she will playonce the change is instituted.

Normative-Reeducation Approach:

110

The normative-Reeducation strategy suggests that peopleare social beings and will adhere to cultural norms and values.Successful change is based on redefining and reinterpretingexisting norms and values, and developing commitments to newones.

Change strategy here focuses squarely on culture – whatpeople believe about their world, their work and themselves and theways in which people behave so as to be consistent with thesebeliefs. Ordinarily, culture doesn’t change quickly and certainly notovernight. This, then, is not the strategy of choice in a turnaroundsituation on short deadlines. Moreover, an organization’s culture isas much in the grip of the informal organization as it is the formalorganization. For this reason, this strategy works only when therelationships between the formal and informal organizations are atleast cordial and hopefully harmonious.

This approach can be very difficult and time-consumingbecause the change agents and sponsor must study the existingvalues and beliefs of a group. It requires unfreezing the currentnorms so that change can take place so that a new set of normscan be refrozen to solidify the acceptance of the new way of doingthings by the group. Some key principles include:

Capacity for change is directly related to a person’sparticipation in a group.

Effective change requires changing something not only aboutthe individual’s values and belief’s, but also the values andbeliefs that make up the existing group’s culture.

Bias and prejudice towards guarding one’s closely held beliefand values diminishes one’s ability to think rationally.

Power-Coercive Approach:

The Power-Coercive strategy attempts to gain compliancefrom the change targets through the exercise of power, authority,rewards or threat for non-conformance.

Two major factors influencing the choice of this strategy aretime and the seriousness of the threat faced. If the organization sitsastride the fabled “burning platform,” the threat is grave and thetime for action is limited. The metaphor of a burning platform isuseful but only if all concerned can in fact see that the platform ison fire. This is rarely the case in an organization. Few companiesare filled with people who understand the way the business worksand fewer people still appreciate the threats it faces or theopportunities it encounters.

111

As Davidson observes, People’s dependency on anorganization dictates how effective the power-coercive approachand use of sanctions can be. If the people are highly dependent onthe organization; live paycheck to paycheck; have few jobalternatives; are not financially, mentally prepared to walk, you areon relatively safe ground using power-coercive approach judiciously(90-91)

The objective is to change the behavior of the targets so thattheir new behavior supports the change effort. Davidson points outthat sanctions should be imposed on an individual level and shouldfocus on what an individual values and what they dread losing – abonus, a paycheck or a position within the organization. A changeagent or sponsor can lose credibility, if they issue a warning orsanction that they do not fully intend to carry out.

Environmental-Adaptive Approach:

People oppose loss and disruption but they adapt readily tonew circumstances. Change is based on building a neworganization and gradually transferring people from the old one tothe new one.

Following this approach, the change agent attempts to makethe change permanently by abolishing the old ways and institutingthe new structure as soon as possible. A much less drasticexample would be upgrading everyone’s word processing softwareover the weekend so that when everyone returned to work onMonday, they would have no choice but using the new softwarepackage.

Time frames are not a factor. This strategy can work undershort time frames or longer ones. However, under short timeframes, a key issue will be that of managing what could beexplosive growth in the new organization and, if it is not adequatelyseeded with new folks, the rapid influx of people from the oldculture can infuse the new organization with the old culture.

Although this approach may be effective in certain situations,it is important that the targets of change assimilate the change asquickly as possible in order to adapt to the change as soon aspossible. Some ways may include helping the targets of changesee the benefits and showing them how the new way is similar totheir old one.

A single strategy however, may not be effective in everysituation. A more useful approach may be combining the differentstrategies, depending on the impact of the change and theorganization.

112

6.3.2 Implement the Change Management Plan and TrackProgress:

Once the strategies for the change management plan havebeen defined, the next step entails implementing the plan andtracking its progress. Although tracking progress should beintegrated into the overall project plan using the tools, such asGantt chart, PERT chart and so on.

The effective line of communication is the critical issue forensuring that the change takes place as planned. The project teamand project sponsor create and open channels of communication. Itis important especially when delivering certain type of news. Forexample a richer media, such as face-to-face communication, isgenerally preferable when delivering important news.

The open channels of communication should be both ways.The project team and sponsor must communicate effectively withthe various groups within the organization affected by the change,and in turn these groups must be able to communicate effectivelywith the project team and sponsor. Web sites, e-mails, memos andnewsletters can be mediums for effective communication.

Evaluate Experience and Develop Lessons Learned:

As the project team carries out the change managementplan, they will learn from their experiences. These experiencesshould be documented and made available to other team membersand other projects. At the end of the project, the overall success ofthe change management plan is evaluated.

6.4 DEALING WITH RESISTANCE AND CONFLICT

Resistance and conflict are a natural part of change. In thissection, we will look at the nature of resistance and conflict andseveral approaches for dealing with these.

Resistance:

With change, comes resistance. Regardless of how clearand concise your change management plan is, you will find varyinglevels of resistance and people questioning the motive for change.

Resistance to change comes for many valid reasons. Forexample, someone may resist for genuine interest – someone may

113

resist an IS because the response time is too slow or because itdoes not provide the feature that were specified as part of therequirements. Resistance like this is healthy and should beencouraged early in the change initiative. On the other hand,resistance due to cultural or behavioral reasons is harder torationalize.

Kotter and Schlesinger set out the following six changeapproaches to deal with resistance to change:

Education and Communication - Where there is a lack ofinformation or inaccurate information and analysis. One ofthe best ways to overcome resistance to change is toeducate people about the change effort beforehand.

Participation and Involvement - Where the initiators do nothave all the information they need to design the change andwhere others have considerable power to resist. Whenemployees are involved in the change effort they are morelikely to buy into change rather than resist it.

Facilitation and Support - Where people are resisting changedue to adjustment problems. Managers can head-offpotential resistance by being supportive of employees duringdifficult times.

Negotiation and Agreement - Where someone or somegroup may lose out in a change and where that individualor group has considerable power to resist. Managers cancombat resistance by offering incentives to employees not toresist change. This can be done by allowing changeresistors can be offered incentives to leave the companythrough early buyouts or retirements in order to avoid havingto experience the change effort.

Manipulation and Co-option - Where other tactics will notwork or are too expensive. Kotter and Schlesinger suggestthat an effective manipulation technique is to co-opt withresisters.

Explicit and Implicit Coercion - Where speed is essential andto be used only as last resort. Managers can explicitly orimplicitly force employees into accepting change by makingclear that resisting to change can lead to losing jobs, firing,transferring or not promoting employees.

Conflict:

Closely associated with resistance is the concept of conflict.Conflict arise when people perceive that their interests and valuesare challenged or not being met. It is important to identify potentialconflicts as early as possible so that the conflict can be addressed.

114

There are 3 different views of conflict, these are

(i) Traditional view – According to this conflict leads to poorperformance, aggression and devastation if left escalate.Therefore, it is important to manage conflict bysuppressing it before it occurs as soon as possible.

(ii) Contemporary view – This view suggests that conflict isinevitable and natural. Depending on how conflict ishandled, conflict can be either positive or negative. Thepositive conflict should be encouraged and negativeconflict in check.

(iii) Interactionist View – Interactionist view holds suggeststhat conflict is an important and necessary ingredient forperformance. The project manager should occasionallystir the pot in order to encourage conflict to anappropriate level so that people engage in positiveconflict.

For the project manager and project team, the seeds ofresistance can easily lead to negative conflicts. Blake and Mouton(1964) and Verma (1998) describe five approaches for dealing withconflict.

Avoidance – Avoiding conflict focuses on retreating,withdrawing conflict. It may be appropriate when youcan’t win, the stakes are low, or gaining time isimportant. Avoidance may not be useful when theimmediate, successful resolution of an issue isrequired.

Accommodation – This approach is useful when tryingto reach an overall goal, when the goal is importantthan the personal interests of the parties involved.

Forcing – This approach is useful when a person useshis or her dominant authority to resolve the conflict.Forcing results in a win-lose situation in which onegains at the other’s expense.

Compromise – It includes both forcing andaccommodation approaches, compromising isbargaining. In this case, no party actually wins andnone actually loses.

Collaboration – This approach requires confrontingand attempting to solve the problem by incorporatingdifferent ideas, viewpoints and perspectives.

115

Collaboration is the best approach when the risks andbenefits are high.

Each conflict situation is unique and the choice of an approach toresolve 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.

6.4.1 Polarity Management:

The project manager or project team is faced with a conflictsituation that appears to have no solution. When two sides (i.e.advocates of change and those resisting change) end up in apolarity where each side can only see the upsides or advantages oftheir pole and the downsides or disadvantages of the other. Formany, this is difficult dilemma that can create even more resistanceand conflict.

According to Barry Johnson, the problem is that we oftenframe a problem as something that can be solved by choosing oneside over another. Crusading is the activity people engage in whenthey want to make things better by moving away from the downsideof one pole to the upside of the opposite pole. Tradition-Bearing isthe activity people engage in to defend the upside of the status quoand to point out the necessity of avoiding the downside of theopposite point of view. Crusaders are those who want to changethe status quo and are supporters of change. They contribute byidentifying the downsides of the current pole and provide theenergy to move away from the current pole. Tradition Bearers - areat the opposite end of the pole and wish to preserve the best of thepast and present and help identify things that should be preserved.Using a tool Polarity mapping, we can see the upsides anddownsides that each side is advocating. Figure 6.5 provides anexample of a polarity map for implementing a new word processingapplication.

In this figure the upper left quadrant is the TraditionalBrearers’ view of the upsides for keeping the current wordprocessing software package are listed, while the Crusaders’ viewof the upsides for upgrading to a new word processing package arelisted in the upper right quadrant.

116

Figure 6.5

The conflicts occur in the lower two quadrants, for examplepeople who advocates upgrading to a new word processingpackage may focus on the upsides of the upper right quadrant (C+).Similarly those in favor of maintaining the status quo will focus onthe quadrants TB+ and TB-. Often the upside of one quadrant (i.e.,familiarity) becomes a downside in the opposite quadrant (i.e., willtake time to learn). Subsequently resistance and conflict escalateunless both sides see the entire picture.

Johnson suggests that before using polarity management, bothsides should:

Clarify what you value and what you do not want to lose. Let the other side know that you are aware of the downsides

of the pole. Assure the other side that you want to maintain the upsides

of their pole.

Polarity mapping helps people “get away” from seeing theircurrent initiative as being the only “solution to the problem” and nota case of choosing one idea over another.

The key to polarity management is recognizing that bothpolarities must be managed simultaneously. In the previousexample of word processing, if upgrading to a new word processingpackage both groups may try to come up with training plan flexibleenough so that both groups get what they want.

117

6.5 SUMMARY

In this chapter, we saw the critical component of business,can be achieved successfully using the ADKAR procedure. Welooked at change as a process. Kurt Lewin introduced the conceptof Force Field Analysis, in which we try to understand the drivingand resisting forces that push and repel the change. Lewis model ofchange helps us to understand that we must unfreeze the currentstate until the desired new state is reached.

In this chapter we understood how to develop effects changemanagement plan. The change management should focus onadopting a strategy to support the change. The plan should centeron implementing the plan and tracking its progress. The polaritymanagement was introduced as a tool that provides a collaborativeapproach for dealing with conflict and resistance.

Sample Questions:

1. Define change management. Describe the stages of Lewin’smodel for change.For solution Refer 7.2.2

2. Describe any two approaches to develop a strategy for change.For Solution Refer 7.3.1

3. In your own words, describe polarity management.Refer 7.4.1

References:

Information Technology Project Management – Providingmeasurable organizational value by Jack T. Marchewka.

http://home.att.net/~OPSINC/four_strategies.pdf

http://www.valuebasedmanagement.net/methods_kotter_change_approaches.html

http://www.pcrest.com/centers/hinds/FI_reading.htm

http://www.businessballs.com/elisabeth_kubler_ross_five_stages_of_grief.htm

http://www.pcrest.com/centers/hinds/FI_reading.htm

Schein, E. H. (1995). Kurt Lewin’s change theory in the field and inthe classroom: Notes toward a model of managed learning [WWWdocument] (74 paragraphs). URL http://www.sol-ne.org/res/wp/10006.html [2002, March 20].http://www.a2zpsychology.com/articles/kurt_lewin's_change_theory.htm [2004, September 9].

118

7PROJECT IMPLEMENTATION

Unit Structure:

7.0 Objectives

7.1 Introduction

7.2 Project Implementation

7.2.1 Direct Cutover

7.2.2 Parallel

7.2.3 Pilot

7.2.4 Phased

7.3 Administrative Closure

7.3.1 Project Sponsor Acceptance

7.3.2 The Final Project Report

7.3.3 The Final Meeting and Presentation

7.3.4 Closing the Project

7.4 Project Evaluation

7.5 Chapter Summary

7.0 OBJECTIVES

After reading this chapter, you will be able to:

Describe the approaches to information systemimplementation and installation. (i) direct cutover (ii) parallel(iii) pilot (iv) phased

Describe the process associated with project closure toensure that the project is closed in an orderly manner.

Identify the different types of project evaluations.

7.1 INTRODUCTION

In this last chapter we will focus on implementation of aproject, closure and the project review or evaluation. The Projectimplementation focuses on installing or delivering the project’smajor deliverables in the organization. Implementation is the stagewhere all the planned activities are put into action. Examples for

119

information system project implementation would be the installationof new databases and application programs, and the adoption ofnew manual procedures etc.,

In general, implementing the product of an IT project canfollow one of the four approaches. These approaches are directcutover, parallel, phased or pilot. Each approach has uniqueadvantages and disadvantages that make a particular approachappropriate for a given situation.

As you know a project has a definite beginning and a definiteend. Once the project is implemented, the project manager and histeam must prepare for closing the project. A project is properlyclosed for two reasons. Firstly, there is a tendency for projects todrift on and become, or develop into, other projects. Secondly, it isimportant to ensure that the work of the project team isacknowledged and that the lessons to be learned from the projectare formally investigated and recorded for use on the next project.

Once the project is closed, the project manager shouldevaluate each project team member individually in order to providefeedback to the individual about his performance on the project. Inaddition, the project should be reviewed by an impartial outsideparty. An audit or outside review can provide valuable insight onhow well the project was managed and on how well the projectmembers functioned as a team.

The project’s overall goal was defined as the MOV, orMeasurable Organizational Value. It is clearly defined and agreedupon in the early stages of the project that whether the project issuccessful, as defined by its MOV.

7.2 PROJECT IMPLEMENTATION

After developing the project, the IS is transferredsuccessfully from the development and test environment to theoperational environment of the customer. Choosing aninappropriate implementation approach can negatively impact theproject’s remaining schedule and budget. In general, the projectteam can take one of three approaches for implementing the IS.These approaches are (i) direct cutover (ii) parallel (iii) pilot and (iv)phased

7.2.1 Direct Cutover:

The direct cutover approach, as illustrated in figure 7.1produces the changeover from old system to the new systeminstantly.This approach can be effective when quick delivery of the

120

new system is critical and this approach may also be appropriatewhen the system’s failure will not have a major impact on theorganization i.e., the system is not mission critical.

Figure 7.1

Companies often choose the direct cutover approach forimplementing commercial software package. Although there aresome advantages to using the approach, there are also a numberof risks involved that generally make this the least favoredapproach. Using this approach you may think as walking a tightropewithout a safety net. You may get from one end of the tightrope toother quickly, but not without a great deal of risk. Subsequently,there is no going back to the old system to the new system. As aresult, the organization could experience major delays, lostrevenues and missed deadlines. The pressure of assuring thateverything is right can create a great deal of stress for the projectteam.

7.2.2 Parallel:

Parallel approach as shown in figure 7.2 is the method inwhich both the new system and the old system will operate at thesame time, for a specified period of time, in order to check the newsystem for complexities.

121

Figure 7.2

Data is input in both system and the results are verified. Thisapproach is impractical if the systems are dissimilar or does notsupport each other. The cost using this approach is relatively high,because both systems are operating requiring more man power interms of management. Using this approach provides confidencethat the new system is functioning and performing properly beforerelying on it entirely. It is also impractical to use this approach asthe new system and old system technically incompatible.

7.2.3 Pilot:

It is the combination of both direct cutover and parallelapproach. The pilot method involves implementing the new systemat a selected location like a branch office, one department in acompany, etc. – called pilot site, and the old system continues tooperate for the entire organization.

Risk and cost, associated in this method are relatively less,because only one location runs the system and the new system isonly installed and implemented at pilot sites; reducing the risk offailure. After the new system proves that the system is successfullyat the pilot site, it is implementing in the rest of the organization,usually using the direct cutover method.

7.2.4 Phased:

The Phased approach allows implementing the new systemin phases or modules or stages in different parts of the organizationincrementally as shown in the figure 7.3. E.g., an organization may

122

implement an accounting information system package by firstimplementing the general ledger component, then accountspayable etc.

Figure 7.3

This method is one of the least risky becauseimplementation only takes effect in part, incase an error goeswrong with the new system, only that particular affected part is atrisk. A phased approach may also allow the project team to learnform its experiences during the initial implementation so that thelater implementations run smoothly.

Although the phased approach may take more time than thedirect cutover approach, it may be less risky and muchmanageable. After all the modules have been tested independentlyit is possible to implement the new system in the organization,which would be error free. Also, overly optimistic target dates orproblems experienced during the early phases of implementationmay create a chain reaction that pushes back the scheduled datesof the remaining planned implantations.

7.3 ADMINISTRATIVE CLOSURE

Although all projects come to an end, a project can beterminated for any number of reasons. Gray and Larson (2000)define five circumstances for ending a project: normal, premature,perpetual, failed and changed priorities.

Normal – A project that completed as planned. The projectscope is achieved within cost, quality and scheduleobjectives with some modification and variation along theway. The project is transferred to the project sponsor and the

123

end of the project is marked with a celebration, awards for agood job.

Premature – A project team may be pushed to complete aproject early even though the system may not include all ofthe envisioned features or functionality.

Perpetual – These projects never seem to end. Theseprojects may result from delays or a scope or MOV that wasnever clearly defined. Then the project sponsor may attemptto add on various features to the system, which results inadded time and resources that increase the project scheduleand drain the project budget. Attention to defining andagreeing to the project’s MOV, the project scope processes,and timely project reviews can reduce the risk of perpetualprojects.

Failed – Sometimes projects are just unsuccessful. Ingeneral an IT project fails if insufficient attention is paid tothe people, processes or technology.

Changed Priority – In some cases, a project may beterminated as a result of a change in priorities. Financial oreconomic reasons may dictate that resources are no longeravailable to the project. This change happens when theoriginal importance of the project was misrepresented.

Ideally a project is closed under normal circumstances.Unfortunately, closing a project does not often happen. As J.Davidson Frame (1998) points out, the project manager and teamshould be prepared to deal with the following realities:

Team members are concerned about future jobs. Oftenthe team members of the project team are borrowed fromdifferent departments. Once the project is finished, they willreturn to their previous jobs. Regardless as the project nearsits end, these project team members may begin to wonderwhat they will do next. For some, there will be rewarding lifeafter the project and for some other looking for the new job.As a result, the project team members may not focus onwhat has to be done to close the project, and wrapping upthe project may be a challenge.

Bugs still exist. Software quality testing may not find all thedefects, and certain bugs may not become known until afterthe system has been implemented. Unless these defectsand bugs are promptly addressed and fixed, the projectsponsor’s satisfaction with the project team and theinformation system may become an issue.

124

Resources are running out. Resources and the projectschedule are consumed from the project’s earliest inception.At the end of the project, both resources and time remainingare usually exhausted. So the project manager may findadequate resources to deal with problems effectively are notavailable.

Documentation attains paramount importance. The ITprojects require system, training and user documentation.Many times, however documentation is put off until the endof the project. As a result, documentation becomesincreasingly important at the end of the project and mayrequire more time and resources to complete.

Promised delivery dates may not be met. Most projectsexperience schedule slippage due to poor projectmanagement, implementation risks, and overly optimisticestimates. Any misjudgment concerning what has to bedone, what is needed to complete the job and how long will ittake will result in a variance between the planned and actualschedule and budget.

The players may posses a sense of panic. The projectstakeholders may experience panic as schedule begins toslip and the resources become exhausted. The sponsor mayworry that the IS will not be delivered on time and within thebudget. As the sense of panic increases, the chances for anorderly closeout grow dim.

A good closeout allows the team to wrap up the project in aneat, logical manner. From an administrative view, this procedureallows for all loose ends to be tied up. From a psychologicalperspective, it provides all of the project stakeholders with a sensethat the project was under control form the beginning through to itsend (Frame 1998)

7.3.1 Project Sponsor Acceptance:

The most important requirement for closure under normalcircumstances is obtaining the project sponsor’s acceptance of theproject. Since acceptance depends heavily on the fulfillment of theproject’s scope, the project manager becomes responsible fordemonstrating that all project deliverables have been completedaccording to the specification.

Rosenau (1998) observes that there are two basic types ofproject sponsors. Shortsighted sponsors and knowledgeablesponsors. Shortsighted sponsors – view the project as a short-term

125

buyer-seller relationship in which getting the most for their money isthe most important criteria for accepting the project.

Knowledgeable sponsors – they have an important stake inthe outcome of the project. They will be actively involvedthroughout the project in a constructive manner.

Regardless of whether the sponsor is shortsighted orknowledgeable, the project manager and team can improve thelikelihood that the project will be accepted if they

(i) Acceptance criteria clearly defined in the early stages ofproject.

(ii) Completion of all project deliverables and milestonesthoroughly documented.

A clearly definition of the project deliverables is an importantconcern for project scope management. Defining and verifying thatthe project scope and system requirements are accurate andcomplete is only one component.

Project milestones ensure that the deliverables are complete.Documenting each deliverables and milestone throughout theproject provides confidence to the project sponsor that the projecthas been completed fully.

7.3.2 The Final Project Report:

The project manager and team should develop a final reportand presentation for the project sponsor and other key stakeholdersto ensure that the project has been completed as outlined in thebusiness case, project charter and project plan.

The report may be circulated to key stakeholders before thepresentation in order to get feedback and to identify any open itemsthat need to be scheduled for completion. Once finalized, the finalproject report provides a background and history of the project. Thereport should include:

(i) Project summaryo Project Descriptiono Project MOVo Scope, Schedule, Budget and Quality Objectives

(ii) Comparison of Planned versus Actualo Original Scope and history of any approved changeso Original scheduled deadline versus actual completion

dateo Original budget versus actual cost of completing the

projecto Test plans and test results

126

(iii) Outstanding Issueso Itemized list and expected completiono Any ongoing support required and duration

(iv) Project Documentation Listo Systems Documentationo User Manualso Training Materialso Maintenance Documentation

7.3.3 The Final Meeting and Presentation:

If the project has been diligent in gaining the confidence of theproject sponsor, the final meeting and presentation should besimple, straightforward. Buttrick (2000) suggests that the finalmeeting is useful for:

Communicating that the project is over. By inviting keystakeholders to the meeting, the project manager is formallyannouncing that the project is over.

Transferring the information system from the project team tothe organization. Although the system may have beenimplemented and is being used by the organization, the finalmeeting provides a formal exchange of the project’s product fromthe project team to the organization.

Acknowledging contribution. The meeting provides a forum forthe project manager to acknowledge the hard work andcontributions of the project team and other key stakeholders.

Getting formal signoff. The meeting can provide a ceremony forthe sponsor or client to formally accept the IS by signing off on theproject.

7.3.4 Closing the Project:

After the project is accepted by the client, a number ofadministrative closure processes remain. Administrative closure isa necessity because once the project manager and team areofficially released from the current project, getting them to wrap upthe last of the details will be difficult. The requirements foradministrative closure include:

Verifying that all deliverables and open items are complete.

Verifying the project sponsor or customer’s formal acceptanceof the project.

Organizing and archiving all project deliverables anddocumentation.

127

Planning for the release of all project resources

Planning for the evaluation and reviews of the project teammembers and the project itself

Closing of all project accounts

Planning a celebration to mark the end of a project.

7.4 Project Evaluation:

There are many views concerning to a project success. Forthe team members, it may be gaining valuable experience and forthe project manager, it may be leading a project that will beprofitable to the firm or a promotion. On the other hand the clientmay view project success in terms of organizational value receivedafter the project is implemented.

There are four types of project evaluations to be conducted.

(i) an individual review of each team member’s performance

(ii) a postmortem review by the project manager and project team

(iii) an audit of the project by an objective and respected outsideparty and

(iv) an evaluation sometime after the project is implemented todetermine whether the project achieved its envisioned MOV.

Individual Performance Review

The project manager should conduct an individualperformance review with each project team member. The projectmanager should focus on the following points:

Begin with the individual evaluation his/herperformance. Evaluating someone’s performance can beemotional experience. Instead of beginning an evaluationwith a critique of the individual’s performance, it is usuallyeffective to begin by asking how that person would evaluateher performance. This system creates a useful dialog thatprovides the individual with more useful feedback.

Avoid “why can’t you be more like//?” People aredifferent and should be evaluated as individuals; comparisoncan have a counter effect. First, the person you praise maynot be the shining star. Second, others may become jealousand look for ways to discredit the individual.

Focus on specific behaviors, not the individual. Whendiscussing opportunities for improvement with a person, it isimportant to focus on specific behavior.

128

Be consistent and fair. The person conducting theevaluation should be aware of how decisions concerning oneperson may affect the entire group and be aware of peopletalk to one another and often compare notes.

Reviews should provide a consensus on improvingperformance. The purpose of conducting review with eachteam member is to provide constructive feedback for them.The individual and the evaluator should agree on what areasthe individual needs to improve upon and how theorganization can support this endeavor.

The meeting can serve to help prepare the individual tomove on and accept the psychological fact that the project will end(Gray and Larson 2000).

Postmortem Review:

The postmortem review should be done before the projectteam is released from the current project. Phillips says. For mostprojects, the post-mortem review should be done at finalacceptance of the project, as soon as possible to the final sign-off.The reasons for this are simple: members of the team are going tomove on to other projects; and the experience of working on theproject will be fresh in everyone's mind soon after it's done. Exactlywhat goes into a post-mortem varies greatly from organization toorganization.

The value of conducting Postmortem review is to - (i) Learnwhat went wrong, so you can avoid it in the future and (ii) Learnwhat worked so that it can transferred to other projects. The focusof this review should include the following:

Review the initial project’s MOV. Was the project’s MOVclearly defined and agreed upon? Did it change over thecourse of the project? What is the probability that it will beachieved?

Review the project scope, schedule, budget and qualityobjectives. How well was the scope defined? How closewere the project schedule and cost estimates to the actualdeadline and budget of the project? Was the qualityobjective met?

Review each of the project deliverables. How effective werethe business case, the project charter, the project plan? Howcould these deliverables be improved?

Review the various project plans and Project ManagementBody of Knowledge areas. The team should review itseffectiveness in all the nine Project management body ofknowledge areas.

129

After the investigation is completed, a report should bedrafted and that the project manager and the project team canshare this with others in the organization. The best practices shouldbe identified and become part of the organization’s IT projectmethodology.

Project Audit:

The individual view and postmortem review provide animportant view of the internal working of the project. To provide amore objective view of the project, an audit by an outside party maybe good for uncovering problems, issues or opportunities forimprovement. An audit means scrutiny, coordination and time isrequired when the project manager’s is often already full. There areconcerns about the outcome and its effects on the team and currentwork as well as careers and advancement. To overcome thisapprehension is proper planning and preparation.

As Gray and Larson (2000) suggest, the depth of the auditdepends on the organization’s size, the importance and size of theproject, the risks involved and the problems encountered. The auditmay involve the project manager and the project team, as well asthe project sponsor and other key project stakeholders. In addition,the third party auditor 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.

The findings of the project audit should be documented, aswell as any lessons learned and best practices.

Evaluating Project Success – The MOV

The MOV – measurable organization value provided thebasis for taking on the project and supported many of the decisionpoints throughout the project life cycle. Although the differentproject stakeholders and players may have different views as towhether the project was a success, it is important to assess thevalue that the project provides the organization. This review may beconducted by several people from both the project sponsor and theorganization or area responsible for carrying out the project. Thisreview should focus on answering the following questions:

Did the project achieve its MOV?

Was the sponsor/customer satisfied?

Was the project managed well?

130

Did the project manager and team act in a professional andethical manner?

What was done right?

What can be done better next time?

The evaluation of the project’s MOV may be intimidating – itcan be the moment of truth as to whether the project was really asuccess. However, a successful IT project that brings measurablevalue to an organization provides a foundation for organizationalsuccess.

7.5 SUMMARY

In this chapter, you looked four approaches toimplementation. Choosing and implementing the correctimplementation approach can have a significant impact on theproject schedule and budget.

Once the IS has been implemented, the project managerand team must plan for an orderly end to the project. Projects mustbe properly closed, regardless of whether the project endssuccessfully or not. Delivery or installation of the IS does not meanthat the project’s sponsor or customer will accept the project.Therefore closure must focus on providing both proof andconfidence that the project team has delivered everything accordingto the business case, project charter and project plan.

Several processes for closing a project were discussed inthis chapter. Before a project is completely terminated, severalreviews are conducted. Lessons learned should be documentedand best practices identified. The performance reviews andpostmortem review should provide preparation for the project audit.The auditor should focus on the specific challenges the projectmanager and his tem faced and review all the project deliverables.

Sample questions:

1. Describe some of the steps for administrative closure.For solution refer 7.3

2. What is implementation? Describe the approaches toimplementing an information system.For solution refer 7.2

3. What is the difference between a shortsighted and aknowledgeable project sponsor? How can making thisdistinction help the project manager during project closure?For solution refer 7.3.1

131

References:

http://www.projectauditors.com/Papers/Your_Project_Has_Been_Selected_for_an__Audit.pdf

Information Technology Project Management – Providingmeasurable organizational value by Jack T. Marchewka.

http://www.spottydog.u-net.com/guides/close/frameset.html

http://ivythesis.typepad.com/term_paper_topics/2009/10/exam-question.html

http://facweb.cs.depaul.edu/yele/Course/IT215/Chapter%2009.ppt#570,41,System Changeover

http://gauravgupta28.wordpress.com/

http://www.cioupdate.com/reports/article.php/2202921/Post-Mortems-Key-to-Successful-Future-Projects.htm

http://www.cis.gsu.edu/~mkeil/cis8150/post-project%20audits.pdf