SOFTWARE PROJECT MANAGEMENT

INDEX
PPT No PPT Name Page No.
1 PROJECT MANAGEMENT an Overview LEFT
2 Phases of Software Project 2-9
3 Systems Engineering Process: Project Scoping 10-14
4 Project Scheduling 15-24
5 Project Cost Management 25-31
6 Total Quality Management 32-34
7 Quality Models 35-39
8 Managing People 40-42
9 Change Management 43-45
10 Problem Management 46-48
11 Project Risk Management 49-52
12 Outsourcing Project Management 53-55
13 Quality Initiatives for Financial & Banking Sectors --
14 Dealing with Disasters – COB Project Management --
15 Audit & Controls --
16 PPT 16: 56-57
- Project Implementation
- Closure
17 Software Metrics --

1|Page
 Software Project Management

Software Project Management


Concerned with activities involved in ensuring that software is delivered on time and
on schedule and in accordance with the requirements of the organisations developing and
procuring the software.
Project management is needed because software development is always subject to budget
and schedule constraints that are set by the organisation developing the software.
Software management distinctions:
 The product is intangible.
 The product is uniquely flexible.
 Software engineering is not recognized as an engineering
discipline with the sane status as mechanical, electrical
engineering, etc.
 The software development process is not standardised.
 Many software projects are 'one-off' projects.
Phases of a Software Project: 

Software Scope
1. Software scope describes
 The functions and features that are to be delivered to end users
 The data that are input to and output from the system
 The "content" that is presented to users as a consequence of using the software
 The performance, constraints, interfaces, and reliability that bound the system
2. Scope can be defined using two techniques :
 A narrative description of software scope is developed after communication with all
stakeholders
 A set of use cases is developed by end users
3. After the scope has been identified, two questions are asked
 Can we build software to meet this scope?
 Is the project feasible?
4. Software engineers too often rush (or are pushed) past these questions
5. Later they become mired in a project that is doomed from the onset

2|Page
Feasibility
After the scope is resolved, feasibility is addressed. Software feasibility has four dimensions:
1. Technology –
Is the project technically feasible? Is it within the state of the art? Can defects be
reduced to a level matching the application's needs?
2. Finance –
Is is financially feasible? Can development be completed at a cost that the software
organization, its client, or the market can afford?
3. Time – Will the project's time-to-market beat the competition?
4. Resources –
Does the software organization have the resources needed to succeed in doing the
project?
Another view recommends the following feasibility dimensions: technological, economical,
legal, operational, and schedule issues (TELOS).
Feasibility Study Content
1. Executive Summary
2. Introduction – Purpose/Objective, Targeted Audience, Abbreviations
3. Justification – Problem Statement, Organizational Impact, Business Impact, Process
Impact, Solution Objectives
4. Solution – Solution Statement, Anticipated Improvements, Solution Impact, Solution
Rationale
5. Alternatives – Alternatives Description, Comparison Matrix
6. Cost – Benefit Analysis – Approach and Tools, Values

Make/Buy Decision
It is often more cost effective to acquire rather than develop software. Managers have
many acquisition options
 Software may be purchased (or licensed) off the shelf
 “Full-experience” or “partial-experience” software components may be acquired and
integrated to meet specific needs
 Software may be custom built by an outside contractor to meet the purchaser’s
specifications

3|Page
The make/buy decision can be made based on the following conditions
 Will the software product be available sooner than internally developed software?
 Will the cost of acquisition plus the cost of customization be less than the cost of
developing the software internally?
 Will the cost of outside support (e.g., a maintenance contract) be less than the cost of
internal support?

Estimation of Project Cost and Effort


Estimation is the process of finding an estimate, or approximation, which is a value
that can be used for some purpose even if input data may be incomplete, uncertain, or
unstable.
Factors Affecting Project Estimation:
The accuracy of a software project estimate is predicated on
 The degree to which the planner has properly estimated the size (e.g., KLOC) of the
product to be built
 The ability to translate the size estimate into human effort, calendar time, and money
 The degree to which the project plan reflects the abilities of the software team
 The stability of both the product requirements and the environment that supports the
software engineering effort.

Options for achieving reliable cost and effort estimates

 Delay estimation until late in the project (we should be able to achieve 100% accurate
estimates after the project is complete)
 Base estimates on similar projects that have already been completed
 Use relatively simple decomposition techniques to generate project cost and effort
estimates
 Use one or more empirical estimation models for software cost and effort estimation
Option #1 is not practical, but results in good numbers
Option #2 can work reasonably well, but it also relies on other project influences being
roughly equivalent
Options #3 and #4 can be done in tandem to cross check each other

4|Page
Different Approaches of Project Estimation:
A. Decomposition techniques
 These take a "divide and conquer" approach
 Cost and effort estimation are performed in a stepwise fashion by breaking down a
project into major functions and related software engineering activities
Before an estimate can be made and decomposition techniques applied, the planner
must
 Understand the scope of the software to be built
 Generate an estimate of the software’s size
Then one of two approaches are used
1. Problem-based estimation
 Based on either source lines of code or function point estimates
2. Process-based estimation
 Based on the effort required to accomplish each task
Approaches to Software Sizing
a. Function point sizing
 Develop estimates of the information domain characteristics
b. Standard component sizing
 Estimate the number of occurrences of each standard component
 Use historical project data to determine the delivered LOC size per standard
component
c. Change sizing
 Used when changes are being made to existing software
 Estimate the number and type of modifications that must be accomplished
 Types of modifications include reuse, adding code, changing code, and deleting code
 An effort ratio is then used to estimate each type of change and the size of the change
The results of these estimates are used to compute an optimistic (low), a most likely, and a
pessimistic (high) value for software size

Problem-Based Estimation:
1. Start with a bounded statement of scope
2. Decompose the software into problem functions that can each be estimated
individually
3. Compute an LOC or FP value for each function

5|Page
 4. Derive cost or effort estimates by applying the LOC or FP values to your baseline
productivity metrics (e.g., LOC/person-month or FP/person-month)
5. Combine function estimates to produce an overall estimate for the entire project
6. In general, the LOC/pm and FP/pm metrics should be computed by project domain
 Important factors are team size, application area, and complexity
7. LOC and FP estimation differ in the level of detail required for decomposition with
each value
a) For LOC, decomposition of functions is essential and should go into
considerable detail (the more detail, the more accurate the estimate)
b) For FP, decomposition occurs for the five information domain characteristics
and the 14 adjustment factors External inputs, external outputs, external
inquiries, internal logical files, external interface files
8. For both approaches, the planner uses lessons learned to estimate an optimistic, most
likely, and pessimistic size value for each function or count (for each information
domain value)
9. Then the expected size value S is computed as follows:

S = (Sopt + 4Sm + Spess)/6

10. Historical LOC or FP data is then compared to S in order to cross-check it

Process-Based Estimation
1) Identify the set of functions that the software needs to perform as obtained from the
project scope
2) Identify the series of framework activities that need to be performed for each function
3) Estimate the effort (in person months) that will be required to accomplish each
software process activity for each function
4) Apply average labor rates (i.e., cost/unit effort) to the effort estimated for each
process activity
5) Compute the total cost and effort for each function and each framework activity
6) Compare the resulting values to those obtained by way of the LOC and FP estimates
a) If both sets of estimates agree, then your numbers are highly reliable
b) Otherwise, conduct further investigation and analysis concerning the function
and activity breakdown

6|Page
B. Empirical estimation models
Offer a potentially valuable estimation approach if the historical data used to seed the
estimate is good
Estimation models for computer software use empirically derived formulas to predict
effort as a function of LOC or FP.The Resultant values computed for LOC or FP are entered
into an estimation model
The empirical data for these models are derived from a limited sample of projects.
 Consequently, the models should be calibrated to reflect local software
development conditions
What is COCOMO?
COCOMO Stands for COnstructive COst Model which is Introduced by Barry Boehm
in 1981 in his book “Software Engineering Economics” Became one of the well-known and
widely-used estimation models in the industry
It has evolved into a more comprehensive estimation model called COCOMO II
COCOMO II is actually a hierarchy of three estimation models. As with all estimation
models, it requires sizing information and accepts it in three forms: object points, function
points, and lines of source code
COCOMO Models
1. Application composition model - Used during the early stages of software engineering
when the following are important
a. Prototyping of user interfaces
b. Consideration of software and system interaction
c. Assessment of performance
d. Evaluation of technology maturity
2. Early design stage model – Used once requirements have been stabilized and basic
software architecture has been established
3. Post-architecture stage model – Used during the construction of the software
COCOMO Cost Drivers are
1. Personnel Factors are Applications experience, Programming language experience,
Virtual machine experience, Personnel capability, Personnel experience, Personnel
continuity, Platform experience, Language and tool experience
2. Product Factors are required software reliability, Database size, software product
complexity, and required reusability, Documentation match to life cycle needs,
Product reliability and complexity.

7|Page
 3. Platform Factors are Execution time constraint, Main storage constraint, Computer
turn-around time, Virtual machine volatility, Platform volatility, Platform difficulty
4. Project Factors are Use of software tools, Use of modern programming practices,
Required development schedule, classified security application, Multi-site
development, Requirements volatility

What is Function Point Analysis (FPA)?

 It is designed to estimate and measure the time, and thereby the cost, of developing new
software applications and maintaining existing software applications.
 It is also useful in comparing and highlighting opportunities for productivity
improvements in software development.
 It was developed by A.J. Albrecht of the IBM Corporation in the early 1980s.
 The main other approach used for measuring the size, and therefore the time required, of
software project is lines of code (LOC) – which has a number of inherent problems.
How is Function Point Analysis done?
Working from the project design specifications, the following system functions are
measured (counted):
1. Inputs
2. Outputs
3. Files
4. Inquires
5. Interfaces
System comprises of many modules
Estimate separately for each module
and add the function points to get
system function points

Example
 A Banking system could have customer, account, cash management, Cheque
processing and interest computation modules
 Let us focus on Interest computation = PNR/100

8|Page
 These function-point counts are then weighed (multiplied) by their degree of
complexity:
Step 1: Step 2:

Step 3:

Because function point analysis is independent of language used, development

platform, etc. It can be used to identify the productivity benefits of One programming
language over another, One development platform over another , One development
methodology over another, One programming department over another, Before-and-
after gains in investing in programmer training and so forth . . .

9|Page
 Systems Engineering Process: Project Scoping
Scope Process
Primarily Concerns what is and is not included in projects and its deliverables.
The main purpose of the define scope process is drawing the boundaries of the project,
outlining the work that will be delivered throughout the project and defining the major
deliverables of the project.

Project Scooping

Basics of Requirements Gathering
A. It’s All About the Customer
B. Process Mapping
C. Process Analysis
D. Requirements Documentation

Key to requirement gathering are Good Communication Skills, Good Listening

Skill, Put it in writing. Examples confirming your understanding, validating your findings,
confirming it is within the scope.

A. It’s all about the Customer

Create a Customer Partnership (Extending the Preliminary Investigation Findings)
Step 1: Obtain authorization to proceed.
Step 2:
 Identify the necessary information.
 Identify Next Level Info Needed.

Step 3: Initiate a fact-finding search

 Obtain & analyze org charts to determine WHO to interview
 Conduct interviews with appropriate departments/customers
 Review current system documentation
 Observe current operations/process
 If necessary, conduct brief survey
 Cross-Functional Steering Team
 Develop Current State Process Docs (include strengths & weaknesses)

10 | P a g e
  Develop Current Functionality Docs
 Observe Current State & Adjust Docs
 Validate w/End Users & Adjust Docs
Step 4: Analyze collected information
 Develop Next Gen Process Docs.
 Develop Next Gen Functional Docs.
 Validate w/End Users & Adjust Docs.
Step 5: Present findings & recommendations to management

B. Process Mapping

Recall Flow Chart Guidelines

1. Boxes indicate process steps
2. Arrows indicate the process flow
3. Columns can be used to indicate function or human role (I.e., buyer) involved
4. Multiple entry and exit points are allowed
5. Shows cross-functional flows
6. Indicate conditional paths w/comments on arrows
The Facts All work can be viewed as a process, all work can be mapped, and all activities are
measurable.
Typical Supplier/Owner/Customer Interests in Clear understanding of steps & importance
Clear understanding of time involved, Efficiency, Reliable results.

11 | P a g e
C. Process Analysis
 During Define Scope process, product analysis is done to produce a detailed scope in the
end.
 During product analysis, objectives and description of the product stated by the
customer or sponsor are analysed.
 After analysis, it is expected to reach tangible project deliverables. Because customer
requirements or expectations are just explanations or statements.
 After evaluation, these must be addressed with project deliverables and once these are
produced in the project, customer acceptance must be acquired respectively.

Process Mapping & Analysis

12 | P a g e
D. Requirements Documentation
Variety of Common Documents are :
1. High-Level Requirements (Process/Functionality) Document
• Typically in MS Word or Adobe PDF
• Typically 20-40 pages in length (max 50 pages)
• Provide general flavor of system objectives, expected use & functionality information
• Release priority if appropriate
• Clear indication of people processing vs. automated
• Document Edit Log
• Table of Contents
• Executive Summary (1-2 paragraphs)
• Business Attributes Summary
• User Roles Involved
• Supply Chain &/or Product Attributes Summary
• 1-4 Most Critical Processes/Steps
• Business Process Step General Information are User Actions, Frequency,
Functionality Required,Small Examples to Articulate Desired Support
• Appendices with Really Detailed Stuff (I.e, Report List)
2. Functionality Hit List :
• Line items of functionality needs
• It Contents are Functional Item ID,Process & Sub-Process ,Functionality Group,
Functionality , Description , Functionality Priority ,Targeted Release
3. Use Cases
• Represents steps in a specific process
• External entity (actor or role) requests system to perform process or function
• Examples:
– Buyer orders a book on Amazon.com
– Driver pulls in & requests a car wash
– Student shows up for a class
• Use cases can be linked or referenced to other use cases
• Use case Documents are Summary List ,High Level Process Use Cases , Detailed
,Process Use Cases ,Special Function/Exception Handling Use Cases

13 | P a g e
 Example of Detailed Process Use Cases :

14 | P a g e
 Project Scheduling

Introduction
A project is a collection of tasks that must be completed in minimum time or at
minimal cost.
Objectives of Project Scheduling
• Completing the project as early as possible by determining the earliest start and finish
of each activity.
• Calculating the likelihood a project will be completed within a certain time period.
• Finding the minimum cost schedule needed to complete the project by a certain date.
• Investigating the results of possible delays in activity’s completion time.
• Progress control.
• Smoothening out resource allocation over the duration of the project.

Identifying the Activities of a Project

1. To determine optimal schedules we need to
a. Identify all the project’s activities.
b. Determine the precedence relations among activities.
2. Based on this information we can develop managerial tools for project control.
3. Breaking down a project into activities is called Work Breakdown Structure (WBS)
4. Each Activity is assigned a cost and person who is responsible for managing cost and
schedule of the activity
5. Project Management tools enable you to zoom in and zoom out to review at different
levels

The PERT/CPM Approach for Project Scheduling:

• The PERT/CPM approach to project scheduling uses network presentation of the
project to
– Reflect activity precedence relations
– Activity completion time
• PERT/CPM is used for scheduling activities such that the project’s completion time is
minimized.
• CPM and PERT have been used to plan, schedule, and control a wide variety of
projects:

15 | P a g e
 - R&D of new products and processes
- Construction of buildings and highways
- Maintenance of large and complex equipment
- Design and installation of new system

Management at KLONE would like to schedule the activities so that the project is completed
in minimal time.
Management wishes to know:
• The earliest and latest start times for each activity which will not alter the earliest
completion time of the project.
• The earliest finish times for each activity which will not alter this date.
• Activities with rigid schedule and activities that have slack in their schedules.

Earliest Start Time / Earliest Finish Time

1. Make a forward pass through the network as follows:
a. Evaluate all the activities which have no immediate predecessors.
i. The earliest start for such an activity is zero ES = 0.
ii. The earliest finish is the activity duration EF = Activity duration.
b. Evaluate the ES of all the nodes for which EF of all the immediate predecessor
has been determined.
i. ES = Max EF of all its immediate predecessors.
ii. EF = ES + Activity duration.
c. Repeat this process until all nodes have been evaluated
i. EF of the finish node is the earliest finish time of the project.

16 | P a g e
2. Latest start time / Latest finish time
Make a backward pass through the network as follows:
a. Evaluate all the activities that immediately precede the finish node.
i. The latest finish for such an activity is LF = minimal project completion
time.
ii. The latest start for such an activity is LS = LF - activity duration.
b. Evaluate the LF of all the nodes for which LS of all the immediate successors has
been determined.
i. LF = Min LS of all its immediate successors.
ii. LS = LF - Activity duration.
c. Repeat this process backward until all nodes have been evaluated.

Slack Times
• Activity start time and completion time may be delayed by planned reasons as well as
by unforeseen reasons.
• Some of these delays may affect the overall completion date.
• To learn about the effects of these delays, we calculate the slack time, and form the
critical path.
• Slack time is the amount of time an activity can be delayed without delaying the
project completion date, assuming no other delays are taking place in the project.

17 | P a g e
Critical Path
• The critical path is a set of activities that have no slack, connecting the START node
with the FINISH node.
• The critical activities (activities with 0 slack) form at least one critical path in the
network.
• A critical path is the longest path in the network.
• The sum of the completion times for the activities on the critical path is the minimal
completion time of the project.

18 | P a g e
Possible Delays
• We observe two different types of delays:
– Single delays.
– Multiple delays.
• Under certain conditions the overall project completion time will be delayed.
• The conditions that specify each case are presented next.

Single Delays
• A delay of a certain amount in a critical activity, causes the entire project to be delayed
by the same amount.
• A delay of a certain amount in a non-critical activity will delay the project by the amount
the delay exceeds the slack time. When the delay is less than the slack, the entire project
is not delayed.

Multiple delays of non critical activities:

19 | P a g e
20 | P a g e
Gantt Charts
• Gantt charts are used as a tool to monitor and control the project progress.
• A Gantt Chart is a graphical presentation that displays activities as follows:
– Time is measured on the horizontal axis. A horizontal bar is drawn
proportionately to an activity’ s expected completion time.
– Each activity is listed on the vertical axis.
• In an earliest time Gantt chart each bar begins and ends at the earliest start/finish the
activity can take place.
Here‘s how we build an Earliest Time Gantt Chart for KLONEPALM 2000

Gantt Charts- Monitoring Project Progress

• Gantt chart can be used as a visual aid for tracking the progress of project activities.
• Appropriate percentage of a bar is shaded to document the completed work.
• The manager can easily see if the project is progressing on schedule (with respect to
the earliest possible completion times).

21 | P a g e
Gantt Charts – Advantages and Disadvantages
• Advantages.
– Easy to construct
– Gives earliest completion date.
– Provides a schedule of earliest possible start and finish times of activities.
• Disadvantages
– Gives only one possible schedule (earliest).
– Does not show whether the project is behind schedule.
– Does not demonstrate the effects of delays in any one activity on the start of
another activity, thus on the project completion time.

Resource Leveling and Resource Allocation(Last Yr PPrQuestion )

• It is desired that resources are evenly spread out throughout the life of the project.
• Resource leveling methods (usually heuristics) are designed to:
 Control resource requirements
 Generate relatively similar usage of resources over time.
• A heuristic approach to “level” expenditures
• Assumptions
 Once an activity has started it is worked on continuously until it is completed.
 Costs can be allocated equally throughout an activity duration.

Step 1: Consider the schedule that begins each activity at its ES.
Step 2: Determine which activity has slack at periods of peak spending.
Step 3: Attempt to reschedule the non-critical activities performed during these peak
periods to periods of less spending, but within the time period between their
ES and LF.
• Management wishes to schedule the project such that
– Completion time is 194 days.
– Daily expenditures are kept as constant as possible.
• To perform this analysis cost estimates for each activity will be needed.

22 | P a g e
 Total Total Cost
Cost Time per
Activity Description (days) Day
A Prototype model design 2250 90 25
B Purchase of materials 180 15 12
C Manufacture of prototype 90 5 18
D Revision of design 300 20 15
E Initial production run 231 21 11
F Staff training 250 25 10
G Staff input on prototype 70 14 5
H Sales traini ng 392 28 14
I Pre-production advertisement 510 30 17
J Post-production advertisement 1350 45 30
Total cost = 5,623

Cost Analyses Using The Critical Path Method (CPM)

• The critical path method (CPM) is a deterministic approach to project planning.
• Completion time depends only on the amount of money allocated to activities.
• Reducing an activity’s completion time is called “crashing.”
Crash time/Crash cost
• There are two crucial completion times to consider for each activity.
– Normal completion time (TN).
– Crash completion time (TC), the minimum possible completion time.
• The cost spent on an activity varies between
• Normal cost (CN). The activity is completed in TN.
• Crash cost (CC). The activity is completed in TC.

Crash time/Crash cost – The Linearity Assumption

• The maximum crashing of activity completion time is TC – TN.
• This can be achieved when spending CN – CC.
• Any percentage of the maximum extra cost
(CN – CC) spent to crash an activity, yields the same percentage reduction of the
maximum time savings (TC – TN).

23 | P a g e
Crash time/ Crash cost - The Linearity Assumption

Crashing activities – Meeting a Deadline at Minimum Cost

• If the deadline to complete a project cannot be met using normal times, additional
resources must be spent on crashing activities.
• The objective is to meet the deadline at minimal additional cost.

PERT/COST
• PERT/Cost helps management gauge progress against scheduled time and cost
estimates.
• PERT/Cost is based on analyzing a segmented project. Each segment is a collection of
work packages.

Work Package – Assumptions

• Once started, a work package is performed continuously until it is finished.
• The costs associated with a work package are spread evenly throughout its duration.

24 | P a g e
 Project Cost Management

What is Cost and Project Cost Management?


Cost is a resource sacrificed or foregone to achieve a specific objective or something given
up in exchange
 Costs are usually measured in monetary units like dollars
Project cost management includes the processes required to ensure that the project is
completed within an approved budget
 Project managers must make sure their projects are well defined, have accurate time
and cost estimates and have a realistic budget that they were involved in approving
Reasons for Cost Overruns
 Not emphasizing the importance of realistic project cost estimates from the outset
 Many of the original cost estimates for IT projects are low to begin with and based
on very unclear project requirements
 Many IT professionals think preparing cost estimates is a job for accountants when in fact
it is a very demanding and important skill that project managers need to acquire
 Many IT projects involve new technology or business processes which involve untested
products and inherent risks
Project Cost Management Processes
There are three project cost management processes:
1. Cost estimating:
Developing an approximation or estimate of the costs of the resources needed
to complete a project
2. Cost budgeting:
Allocating the overall cost estimate to individual work items to establish a
baseline for measuring performance
3. Cost control:
Controlling changes to the project budget

25 | P a g e
Q2. Basic Principles of Cost Management

Most members of an executive board better understand and are more interested in financial
terms than IT terms, so IT project managers must speak their language
1. Cash flow analysis
Determines the estimated annual costs and benefits for a project and the resulting
annual cash flow
Too many projects with high cash flow needs in the same year may not be able to be
supported which will impact profitability
2. Tangible costs or benefits
Those costs or benefits that an organization can easily measure in dollars
A task that was allocated $150,000 but actually costs $100,000 would have a tangible benefit
of $50,000 if the assets allocated are used for other projects
3. Intangible costs or benefits
They are costs or benefits that are difficult to measure in monetary terms
 Costs – resources used to research related areas of a project but not billed to the
project
 Benefits – goodwill, prestige, general statements of improved productivity not easily
translated in dollars
4. Direct costs
• They are costs that can be directly related to producing the products and services of
the project
• Salaries, cost of hardware and software purchased specifically for the project
5. Indirect costs :
They are costs that are not directly related to the products or services of the project,
but are indirectly related to performing the project.Cost of electricity, paper towels
6. Sunk cost
It is the money that has been spent in the past; when deciding what projects to invest
in or continue, you should not include sunk costs
 To continue funding a failed project because a great deal of money has already been
spent on it is not a valid way to decide on which projects to fund
 Sunk costs should be forgotten

26 | P a g e
7. Learning Curve Theory
States that when many items are produced (or tasks are performed) repetitively, the
unit cost of those items decreases in a regular pattern as more units are produced (or more
tasks performed).
8. Reserves
They are the dollars included in a cost estimate to mitigate cost risk by allowing for
future situations that are difficult to predict
9. Contingency reserves
They allow for future situations that may be partially planned for (sometimes called
known unknowns) and are included in the project cost baseline
 Recruiting and training costs for expected personnel turnover during a project
10. Management reserves
They allow for future situations that are unpredictable (sometimes called unknown
unknowns)
 Extended absence of a manager; supplier goes out of business

Q3. Cost Estimating


After developing a good resource requirements list, PMs and their teams must
develop several estimates of the costs for these resources
Project managers must take cost estimates seriously if they want to complete projects within
budget constraints
It’s important to know the types of cost estimates, how to prepare cost estimates, and typical
problems associated with IT cost estimates
There are Three Types of Cost Estimating:
A. Rough order of magnitude (ROM):
A rough order of magnitude (ROM) estimate provides an estimate of what a project
will cost.
 Also referred to as a ballpark estimate, a guesstimate, a swag, or a broad gauge.
 Done very early in a project, often three or more years prior to project completion, or
even before a project is officially started to help PMs Make project selection decisions.
 Accuracy is typically -50 percent to +100 percent, meaning the project’s actual costs
could be 50 percent below the ROM estimate or 100 percent above.

27 | P a g e
  A ROM estimate that actually cost $100,000 would range between $50,000 to
$200,000. The accuracy range is often much wider for IT projects.
 Often IT project estimates for software development are doubled because of the history of
cost overruns
B. Budgetary Estimate
A budgetary estimate is used to allocate money into an organization’s budget.
 Many organizations develop budgets at least two years into the future.
- Budgetary estimates are made one to two years prior to project completion.
 The accuracy of budgetary estimates is typically -10% to +25%
- A budgetary estimate that actually costs $100,000 would range between $90,000
to $125,000 .
C. Definitive Estimate
A definitive estimate provides an accurate estimate of project costs (most accurate of
the three types).
 Definitive estimates are used for making many purchasing decisions for which accurate
estimates are required and for estimating final project costs.
 For example, if a project involves purchasing 1000 personal computers from an outside
supplier in the next three months, a definitive estimate would be required to aid in
evaluating supplier proposals and allocating the funds to pay the chosen supplier.
 Definitive estimates are made one year or less prior to project completion
 Accuracy range is normally -5% to +10%

It is important to provide supporting details (assumptions, project scope, WBS, etc)

used in computing estimates so that it will be easier to prepare updates as needed or similar
estimates on other projects.

28 | P a g e
Q4. Cost Management Plan & Its Tools and Techniques

A cost management plan is a document that describes how the organization will
manage cost variance on the project
 For example, how to respond to proposals from suppliers that are higher or lower than
estimates
 A large percentage of total project costs are often labor costs, so project managers must
develop and track estimates for labor
 Many organizations estimate the number of people or hours they need by department or
skill over the life cycle of a project
Cost Estimation Tools and Techniques :
1. Analogous or top-down estimates:
Use the actual cost of a previous, similar project as the basis for estimating the cost of
the current project
 How similar the current and previous project are determines the accuracy of the estimate.
Using a different language or hardware can skew the estimate
2. Bottom-up estimates or Activity Based Costing :
It involves estimating individual work items or activities and summing them to get a
project total
 The smaller the work items, the better the estimate but these estimates are usually time
intensive and expensive to develop

3. Parametric modeling:
It uses project characteristics (parameters) in a mathematical model to estimate
project costs
 For example, a model might provide an estimate of $50 per line of code for a s/w
development project based on the programming language, level of expertise of the
programmers, size and complexity of the data involved, etc
 Some models may be simpler such as a $10,000 ballpark estimate per workstation in a
large office automation project based on history of similar projects during the same time
period

29 | P a g e
Q5. Explain Cost Budgeting, Cost Control, Earned Value Management (EVM) Rate of
Performance

A. Cost Budgeting
Cost budgeting involves allocating the project cost estimate to individual work items
over time
The WBS is a required input to the cost budgeting process since it defines the work items
An important goal is to produce a cost baseline:
 A time-phased budget that project managers use to measure and monitor cost
performance
 Estimating costs for each major project activity over time provides management with a
foundation for project cost control
 Cost budgeting also provides info for project funding requirements –at what point(s) in
time will the money be needed

B. Cost Control:
Project cost control includes:
 Monitoring cost performance
 Ensuring that only appropriate project changes are included in a revised cost baseline
 Informing project stakeholders of authorized changes to the project that will affect
costs
 Many organizations around the globe have problems with cost control
 Performance review meetings can be a powerful tool to help control project costs
 Knowing you have to report on your progress is an incentive for people to perform
better
 Performance measurement is another important tool for cost control.
 There are many general accounting approaches for measuring cost performance but
earned value management is a tool unique to project management

C. Earned Value Management (EVM)

EVM is a project performance measurement technique that integrates scope, time,
and cost data
 Given a baseline (original plan plus approved changes), you can determine how well the
project is meeting its goals

30 | P a g e
 You must enter actual information periodically to use EVM Was a WBS item completed
or approximately how much of the work was completed Actual start and end dates & its
Actual cost
 More and more organizations around the world are using EVM to help control project
costs
Its Terms are :
1. Planned value (PV):
The planned value (PV), formerly called the budgeted cost of work scheduled
(BCWS), also called the budget, is that portion of the approved total cost estimate planned to
be spent on an activity during a given period
2. Actual cost (AC):
The Actual cost (AC), formerly called actual cost of work performed (ACWP), is the
total of direct and indirect costs incurred in accomplishing work on an activity during a given
period $20,000 AC to accomplish task over two weeks - $15K AC week 1and $5K week 2
3. Earned Value (EV):
The earned value (EV), formerly called the budgeted cost of work performed
(BCWP), is an estimate of the value of the physical work actually completed.
EV is based on the original planned costs for the project or activity and the rate at which the
team is completing work on the project or activity to date

D. Rate of Performance
Rate of performance (RP) is the ratio of actual work completed to the percentage of
work planned to have been completed at any given time during the life of the project or
activity
Brenda Taylor, Senior Project Manager in South Africa, suggests this term and approach
for estimating earned value
For example, suppose the server installation was halfway completed by the end of week 1;
the rate of performance would be 50% because by the end of week 1, the planned schedule
reflects that the task should be 100% complete and only 50% of that work has been
completed The EV would thus be $5,000 after week 1 ($10,000*50%)

31 | P a g e
 Total Quality Management

Quality Management System:

A set of organisational measures which transmit maximum confidence that a given
quality level is being achieved with the adequate resource consumption.
The project delivery should ensure quality management. Here, quality doesn’t always
mean perfection and high quality services, but maintaining consistency in quality across
projects.
The quality to be maintained in a project is decided by the stakeholders, owners and
clients of the project. Quality standards are also defined based on organizational values
and standards.
A quality management process is introduced in a project towards quality planning, quality
assurance and quality control.
Characteristics:
In a project, quality characteristics are defined by the stakeholders. Some of the most
common quality characteristics are performance, functionality, suitability, reliability,
consistency and more.
The levels of quality in these terms are measured as per project and organizational
standards are
 External focus: at the client
 Global approach and as an integral component of the organization strategy
 Horizontal vision within the organization, from top management to staff
 Includes all the concerned parts
 Continuous learning and adaptation to change
Quality management involves typically three phases –
1. Quality Planning:
Here, the quality plan is created. Every plan should have a desired objective or goal
and quality plan is no exception. The goal of quality management should be clearly
communicated to all the stakeholders in a project. After the goal is defined, the measures to
ensure the level of standard should be worked out. How will the customers be satisfied? What
is the level of quality that the stakeholders are expecting? How to determine if the quality
measures will lead to project success? When all the answers to these questions are in place,
tasks should be delegated to respective team members and quality plan is initiated.

32 | P a g e
2. Quality Assurance:
This is a process that moves along with project throughout the lifecycle. Quality
assurance is all about evaluating if a project is moving towards delivering quality services. If
all the quality characteristics are in place the quality plan can proceeding in an effective
manner. When quality goals are not achieved or are not in the process of getting achieved,
necessary steps and corrective actions should be identified. Ensuring corrective actions too
falls in the phase of quality assurance.
3. Quality Control:
Here, operational techniques are used in order to ensure quality standards. Any time a
problem arises relating to quality or if the quality plan is not executed in the desired manner,
corrective actions should be effective. Quality control involves monitoring project results and
delivery to check if they are meeting desired results or not. If not then alternative actions
should be implemented.

Process Mapping
Process mapping is a workflow diagram to bring forth a clearer understanding of a
process or series of parallel processes.

Information required for process Mapping:

 Key Responsibility of the process area.
 Key performance indicators.
 Key Activities of the process area.
 Customers Recipients of each activity output.
 Suppliers of each activity input.
 Key volumes related to an activity.
 Key deliverables of each activity products and services.
 Input methods, material, manpower, information, equipment’s etc

Why What during Process Mapping:

 Tools & techniques used to understand, analyse and document process & activities.
 To Analyse & develop specific areas for improvement and /or future change
initiative’s.
 Establishing a shared knowledge base.
 Produce a range ‘As is’ and ‘To be’ process maps.

33 | P a g e
  Identify efficiencies and where systems can support these.
 Assist in identifying opportunities for improvement.
 Displays the sequential steps involved in converting a specific input into the required
output.
 Understanding of the work process, resource allocation, training etc.
 Improve process by removing non-value add, complexity & constrains.

34 | P a g e
 Quality Models

QUALITY MANAGEMENT PRINCIPLES


1. Customer focus
2. Leadership
3. Involvement of people
4. Process approach
5. System approach to management
6. Continual improvement
7. Factual approach to decision making
8. Mutually beneficial supplier relationships

ISO 9000 (International Organization for Standardization) is about QUALITY :

Quality is defined by customer needs defined in terms of fitness for purpose achieved
through continuous improvement managed through prevention not detection ‘getting it right
at the first time’ measurable.

ISO 9000 - 20 Elements


4. Management Responsibility
5. Quality System
6. Contract Review
7. Design Control
8. Document & Data Control
9. Purchasing
10. Control of Customer Supplied Product
11. Product Identification and Traceability
12. Process Control
13. Inspection and Test Status
14. Control of Inspection, Measuring and Test Equipment.
15. Inspection and Test Status
16. Control of Nonconforming Product
17. Corrective & Preventive Action

35 | P a g e
18. Handling , Storage, Packaging, Preservation and Delivery
19. Control of Quality Records
20. Quality Audits
21. Training
22. Servicing
23. Statistical Techniques

What is CMMI?

CMMI (Capability Maturity Model Integration) is a proven industry framework to
improve product quality and development efficiency for both hardware and software
Sponsored by US Department of Defence in cooperation with Carnegie Mellon University
and the Software Engineering Institute (SEI)
Many companies have been involved in CMMI definition such as Motorola and Ericsson
CMMI has been established as a model to improve business results
CMMI, staged, uses 5 levels to describe the maturity of the organization, same as predecessor
CMM
– Vastly improved version of the CMM
– Emphasis on business needs, integration and institutionalization
The CMMI definition of “Systems Engineering” -
“The interdisciplinary approach governing the total technical and managerial effort
required to transform a set of customer needs, expectations and constraints into a product
solution and to support that solution throughout the product’s life.” This includes both
hardware and software.

36 | P a g e
Maturity Level 1: Initial
• Maturity Level 1 deals with performed processes.
• Processes are unpredictable, poorly controlled, reactive.
• The process performance may not be stable and may not meet specific objectives such
as quality, cost, and schedule, but useful work can be done.
Maturity Level 2 Managed at the Project Level
Maturity Level 2 deals with managed processes. A managed process is a performed
process that is also:
 Planned and executed in accordance with policy
 Employs skilled people
 Adequate resources are available
 Controlled outputs are produced
 Stakeholders are involved
 The process is reviewed and evaluated for adherence to requirements
Processes are planned, documented, performed, monitored, and controlled at the
project level. Often reactive.The managed process comes closer to achieving the specific
objectives such as quality, cost, and schedule.

37 | P a g e
Maturity Level 3 Defined at the Organization Level
Maturity Level 3 deals with defined processes. A defined process is a managed
process that:
 Well defined, understood, deployed and executed across the entire organization.
Proactive.
 Processes, standards, procedures, tools, etc. are defined at the organizational
(Organization X ) level. Project or local tailoring is allowed, however it must be
based on the organization’s set of standard processes and defined per the
organization’s tailoring guidelines.
Major portions of the organization cannot “opt out.”

CMMI Components
• Within each of the 5 Maturity Levels, there are basic functions that need to be
performed – these are called Process Areas (PAs).
• For Maturity Level 2 there are 7 Process Areas that must be completely satisfied.
• For Maturity Level 3 there are 11 Process Areas that must be completely satisfied.
• Given the interactions and overlap, it becomes more efficient to work the Maturity
Level 2 and 3 issues concurrently.
• Within each PA there are Goals to be achieved and within each Goal there are
Practices, work products, etc. to be followed that will support each of the Goals.

38 | P a g e
CMMI Process Areas

39 | P a g e
 Managing People

Personality types
The needs hierarchy is almost certainly an over-simplification of motivation in
practice.
Motivation should also take into account different personality types:
1. Task-oriented;
2. Self-oriented;
3. Interaction-oriented.

1. Task-oriented.
The motivation for doing the work is the work itself;
2. Self-oriented.
The work is a means to an end which is the achievement of individual goals - e.g. to
get rich, to play tennis, to travel etc.
3. Interaction-oriented
The principal motivation is the presence and actions of co-workers. People go to work
because they like to go to work.
Motivation balance
 Individual motivations are made up of elements of each class.
 The balance can change depending on personal circumstances and external events.
 However, people are not just motivated by personal factors but also by being part of a
group and culture.
 People go to work because they are motivated by the people that they work with.
Managing groups
 Most software engineering is a group activity.
 The development schedule for most non-trivial software projects is such that they
cannot be completed by one person working alone.
 Group interaction is a key determinant of group performance.
 Flexibility in group composition is limited because Managers must do the best they
can with available people.

40 | P a g e
Factors influencing group working
A. Group composition.
1. Group composed of members who share the same motivation can be problematic
a. Task-oriented - everyone wants to do their own thing;
b. Self-oriented - everyone wants to be the boss;
c. Interaction-oriented - too much chatting, not enough work.
2. An effective group has a balance of all types.
3. This can be difficult to achieve software engineers are often task-oriented.
4. Interaction-oriented people are very important as they can detect and defuse tensions
that arise.

B. Group leadership
Leadership depends on respect not titular status.There may be both a technical
and an administrative leader.Democratic leadership is more effective that autocratic
leadership.

C. Group cohesiveness.
1. In a cohesive group, members consider the group to be more important than any
individual in it.
2. The advantages of a cohesive group are:
a. Group quality standards can be developed;
b. Group members work closely together so inhibitions caused by ignorance are
reduced;
c. Team members learn from each other and get to know each other’s work;
d. Egoless programming where members strive to improve each other’s
programs can be practised.
3. Cohesiveness is influenced by factors such as the organisational culture and the
personalities in the group.
4. Cohesiveness can be encouraged through
a. Social events;
b. Developing a group identity and territory;
c. Explicit team-building activities.
5. Openness with information is a simple way of ensuring all group members feel part of
the group.

41 | P a g e
D. Group loyalties
1. Group members tend to be loyal to cohesive groups.
2. 'Groupthink' is preservation of group irrespective of technical or organizational
considerations.
3. Management should act positively to avoid groupthink by forcing external
involvement with each group.

E. Group communications.
1. Good communications are essential for effective group working.
2. Information must be exchanged on the status of work, design decisions and changes to
previous decisions.
3. Good communications also strengthens group cohesion as it promotes understanding.
4. Group size: The larger the group, the harder it is for people to communicate with
other group members.
5. Group structure Communication is better in informally structured groups than in
hierarchically structured groups.
6. Group composition Communication is better when there are different personality
types in a group and when groups are mixed rather than single sex.
7. The physical work environment Good workplace organisation can help encourage
communications.

F. Group organization.
Small software engineering groups are usually organised informally without a rigid
structure. For large projects, there may be a hierarchical structure where different groups
are responsible for different sub-projects.
G. Informal groups
 The group acts as a whole and comes to a consensus on decisions affecting the
system.
 The group leader serves as the external interface of the group but does not allocate
specific work items.
 Rather, work is discussed by the group as a whole and tasks are allocated according to
ability and experience.
 This approach is successful for groups where all members are experienced and
competent.

42 | P a g e
 Change Management

What is Change Management?


Definition of change management: Change management is the application of a
structured process and set of tools for leading the “people side” of change to achieve a
desired outcome.
When change management is done well, people feel engaged in the change process
and work collectively towards a common objective, realizing benefits and delivering results.

Change Management is Essentials because changes in Control Board are Prioritizes

Changes and Avoids conflicting changes. Always do one change at a time in one area to
ensure that benefits are not lost

Benefits of Change Management

1. Projects and initiatives that are delivered on time, on budget and with the intended results.
2. Improved employee and stakeholder engagement.
3. Trust and credibility for the next change.
4. Reduce resistance to change.
5. Ability to innovate and move forward.
6. Make it fun!

43 | P a g e
The Business Side of Change

 Ensure the business case and driver behind the change are clearly understood.
 Ensure there is clarity around the actual change and the impacts of that change.
 Ensure there is clarity around how the change will be implemented.
 In order to create an effective change management plan/strategy there must be clarity
around the why, what and how of the change.

Phase 1: Structure for Change

 How will we monitor progress?
 How will we work together?
 What are the ground rules?
 How often will we meet?
 What guidelines should we adopt?
People Side Of Changes

Phase 2: Change Resistance

Use ADKAR as a tool to ensure you have a robust plan and have addressed each
element.
Explore and understand the different types of resistance to ensure you have a robust
change management plan/strategy:
a. Intellectual Resistance
b. Personal Resistance
c. Cultural Resistance
Phase 3: What’s Your Plan?
 It is important to document and write it down.
 Who is going to do what and by when.
 Make it visual, communicate often, celebrate milestones and successes, reward early
adopters.
If you think about it, it is a dream or an idea.
If you talk about it, it becomes exciting.
If you write it down, it can become real.

44 | P a g e
Phase 4: Communication Strategy
 Roles & Responsibilities
 Stakeholder Assessment
 Message Planning
 Effective Messages
 Communications Media
 Sender
 Communications Vehicles
Phase 5: The Feedback Loop
 Determine your mechanism for feedback – be creative!
 Schedule debrief sessions with key stakeholders.
 Determine gaps and create plans to address.
 Use previous planning to manage resistance – tweak plans as necessary to be
successful.
 Celebrate successes!
 Communication is key.

45 | P a g e
 Problem Management

What is Problem Management?


Problem Management is the process responsible for managing the lifecycle of all problems
that happen or could happen in an IT service.
The Primary Goal of Problem Management are :
1. Purpose of Problem Management
2. Role
3. Process
4. Policy

A. Purpose of Problem Management

The Purpose of Problem Management is for Incident, Problem and Services.
1. In case of Incident Something is broken or about to break, Repair as quickly as possible,
open incidents are measured against SLAs.
2. In Case of Problem:
 There is no time SLA target associated with problem resolution. Resolution of the
root cause of a problem may take hours or days or even years.
 Problems do not need prior approvals to be worked and resolved. They only need to
be prioritized to work the most critical problems first.
 If it appears that root cause identification and resolution are not readily apparent and
the impact is medium or high, effort should be focused first on providing a suitable
documented work around.
3. In Case of Service Request :
Routine pleas for help – but nothing is broken. These include items like “can you tell
me Joe Blow’s phone number”, “can you unlock my account”, and “will you reset my
password.”

B. Roles
1. Service Desk
 Ensure that all problems received by the Service Desk are recorded in CRM
 Delegates responsibility by assigning problems to the appropriate provider group for
resolution based upon the categorization rules

46 | P a g e
  Performs post-resolution customer review to ensure that all work services are
functioning properly
2. Quality Assurance
 Owns all reported problems
 Prepare reports showing statistics of problems resolved / unresolved
3. Service Provider Group
 Composed of technical and functional staff involved in supporting services
 Perform root cause analysis of the problem and develop potential solutions
 Test potential solutions and develop implementation plan
4. Problem Reporter
 Anyone within Service Desk can request a problem case to be opened.
 The typical sources for problems are the Service Desk, Service Provider Groups, and
proactive problem management through Quality Assurance.

C. Process

47 | P a g e
 Anyone can request that a problem case be opened.
 All initial information relative to problem will be logged, especially related incidents.
 Before continuing the Service Desk will verify the related service having the issue and
correlate it with an existing service and SLA.
 After problem verification, the Service Desk will attempt to establish incident severity
and impact which define priority.
 Primary root cause analysis will be performed by the Service Provider Group.
 As soon as the problem is clearly documented with identifying symptoms, a known error
record will created within CRM so that if additional incidents occur, they can be tied to
the existing problem.
 Once the solution is determined, it should be implemented following the Change
Management Process.
 Once the solution is implemented and verified, the problem case may be closed.

D. Policy
• Problems must be logged with the Service Desk before they are worked.
• There is no SLA target date connected to problem resolution.
• If a work around for the problem has been discovered, it should be provided to the
Service Desk and logged into CRM.

48 | P a g e
 Project Risk Management

Project Risk:-
An uncertain event or condition that, if it occurs, has a positive or negative effect on
the project objectives.
Project Risk Management:-
Project Risk Management is the art and science of identifying, analyzing, and
responding to risk throughout the life of a project and in the best interests of meeting project
objectives.
Risk Management is often overlooked in projects, but it can help improve project
success by helping select good projects, determining project scope, and developing realistic
estimates.
1. Negative Risk
A dictionary definition of risk is “the possibility of loss or injury”. Negative risk
involves understanding potential problems that might occur in the project and how they might
impede project success. Negative risk management is like a form of insurance; it is an
investment.

2. Risk Can Be Positive

 Positive risks are risks that result in good things happening; sometimes called
opportunities
 A general definition of project risk is an uncertainty that can have a negative or positive
effect on meeting project objectives
 The goal of project risk management is to minimize potential negative risks while
maximizing potential positive risks
3. Risk Tolerance
Risk tolerance is the ability to withstand a risk and still meet the project goals
 Tolerance rises at a decreasing rate for people who are risk-averse
 Those who are risk-seeking have a higher tolerance for risk and their satisfaction
increases when more payoff is at stake
 The risk-neutral approach achieves a balance between risk and payoff.

49 | P a g e
Steps in Project Risk Management Process are:-
1. Planning risk management :
Deciding how to approach and plan the risk management activities for the project.
2. Identifying risks:
Determining which risks are likely to affect a project and documenting the
characteristics of each
3. Performing qualitative risk analysis:
Prioritizing risks based on their probability and impact of occurrence
4. Performing quantitative risk analysis:
Numerically estimating the effects of risks on project objectives
5. Planning risk responses:
Taking steps to enhance opportunities and reduce threats to meeting project objectives
6. Controlling risk:
Monitoring identified and residual risks, identifying new risks, carrying out risk
response plans, and evaluating the effectiveness of risk strategies throughout the life of
the project

50 | P a g e
Identifying Risks
 Identifying risks is the process of understanding what potential events might hurt or
enhance a particular project.
 Another consideration is the likelihood of advanced discovery.
 Risk identification tools and techniques include:
a. Brainstorming
b. The Delphi Technique
c. Interviewing
d. SWOT analysis
A. Brainstorming:
Brainstorming is a technique by which a group attempts to generate ideas or find a
solution for a specific problem by amassing ideas spontaneously and without judgment
 An experienced facilitator should run the brainstorming session
 Be careful not to overuse or misuse brainstorming.
 Psychology literature shows that individuals produce a greater number of ideas
working alone than they do through brainstorming in small, face-to-face groups
 Group effects often inhibit idea generation

B. Delphi Technique
The Delphi Technique is used to derive a consensus among a panel of experts who
make predictions about future developments
 Provides independent and anonymous input regarding future events
 Uses repeated rounds of questioning and written responses and avoids the biasing effects
possible in oral methods, such as brainstorming

C. Interviewing
Interviewing is a fact-finding technique for collecting information in face-to-face,
phone, e-mail, or instant-messaging discussions Interviewing people with similar project
experience is an important tool for identifying potential risks

D. SWOT Analysis
SWOT analysis (strengths, weaknesses, opportunities, and threats) can also be used
during risk identification. Helps identify the broad negative and positive risks that apply to a
project

51 | P a g e
Controlling Risks
Involves executing the risk management process to respond to risk events and
ensuring that risk awareness is an ongoing activity performed by the entire project team
throughout the entire project.
 Workarounds are unplanned responses to risk events that must be done when there are
no contingency plans.
 Main outputs of risk control are:
o Work performance information
o change requests
o updates to the project management plan, other project documents, and
organizational process assets

52 | P a g e
 Outsourcing Project Management

Outsourcing:-
Outsourcing can be defined as the procurement of products or services from an
external vendor, supplier, or manufacturer.
 Analogous to Procurement Management.
 Strategic approach
 Beginning of Outsourcing phenomenon started in 1989 mainly when Kodak outsourced
and increased its profit.
 Outsourcing expanded to include BPO other than just I.T. i.e. accounting, HRM, R&D
etc)
 Outsourcing to other country gives advantage of labor arbitrage i.e. cheap labour.
 Can be organization-level decision or project-level decision.
 Although low cost is one advantage for outsourcing and offshoring, the objective should
be to increase flexibility and quality.

Types of Outsourcing:-
1. Full Insourcing:-
 Products & services would be retained internally.
 Project team is responsible for all the project's processes and scope.
2. Selective Outsourcing:-
 Best approach
 Provides greater flexibility to choose which project processes deliverable should be
outsourced and which should be kept internal
3. Full Outsourcing:-
 An organization or project acquires all products or services from external sources.
 We would have a virtual organization or project.

53 | P a g e
Offshore Outsourcing Myths:-
1. IT offshoring is a new phenomenon: - In 1980's, when production of computer chips
was transferred to Asia.
2. Offshoring is the one strategy a company should pursue to reduce software
development costs: - Using computer aided software engineering tools can improve
productivity and reduce development time.
3. IT work that's shipped overseas will stay there: - offshoring will become less attractive
because work is repetitive and boring, so it will be automated in future.
4. Offshoring will result in significant unemployment in technology sector: - It creates
new global markets for products and services.
5. IT wages will fall across the board because of foreign competition
6. It will become less necessary to teach programming and other technical skills to college
students because these skills won't be in such high demand in the US anymore.
7. By hiring programmers overseas, companies can lower development costs by 80%
or more:- But additional costs must be incurred such as vendor searches, negotiation,
contract development, severance pay for downsized domestic employees, as well as
reduced productivity due to morale issues and completion of knowledge transfer to
vendor.
8. Quality is lower in offshore IT operations: - almost same errors found in both program
made in India and USA.
9. Only routine and mechanical IT tasks are candidates for offshore outsourcing.
10. It's always best to outsource IT work to developing countries with a large, low cost labour
pool of programmers.

Seven Sins of Outsourcing:-

1. Outsourcing activities that shouldn't be outsourced:-
 Outsourcing results in an automatic reduction of cost and an increase in performance.
 However this view is non-realistic and many organizations outsource to mimic their
competitors or success stories in trade journal.
 A loss of control and the risk of the vendor going out of business can have grave
consequences for the company.
2. Selecting the wrong vendor:-
Good vendor should be selected according to two organizations' cultures, as well as a
commitment to continuous improvement, flexibility and a long term relationship.

54 | P a g e
3. Writing a Poor Contract:-
Well-written contract should be precise, complete, provide incentives for the right
behaviour, balanced and flexible.
4. Overlooking Personnel Issues:-
Can have negative impact on employee’s loyalty and sense of job security. Leads to
reduced productivity, dysfunctional behaviours, or a mass exodus of employees.
Organizations must retain and motivate key employees.
5. Losing control over the Outsourced activity
6. Overlooking the hidden costs of Outsourcing: - hidden costs includes searching for
vendors, negotiating and writing the contract, and managing the vendor relationships.
7. Failing to plan an Exit strategy.

55 | P a g e
 Project Implementation & Closure
Q. Project Implementation and explain its different approaches.

Project Implementation:-
When testing is complete and the project team and project manager then become
responsible for ensuring that the information system is transferred successfully from the
development and test environment to the operational environment of the sponsor or
customer's organization.
Choosing an inappropriate implementation approach can negatively impact the project's
remaining schedule and budget.
There are three approaches: - (DPP)
1. Direct Cut-over
2. Parallel
3. Phased
1. Direct Cut-Over
 Old system is shut down, new system is turned on.
 New system simply replaces the old.
Advantage:-
 Effective when quick delivery of the new system is critical or when the existing system is
so poor that it must be replaced as soon as possible.
 Appropriate when system is not mission critical.
 It is important, however, that new system be thoroughly tested so everyone is confident
that few, if any, major problems will arise.
Disadvantages:-
 Least favored approach
 Though its quick, its painful at times.
 There may be no going back one the old system is turned off and the new system is turned
on.
 The organization could experience major delays, frustrated users and customer, lost
revenues and missed deadlines.
 Pressure of ensuring that everything is right or having to deal with problems and irate
users or project stakeholders can create a great deal of stress for the project team.

56 | P a g e
2. Parallel
Implementation allows the old and the new systems to run concurrently for a time. At
some point, the organization switches entirely from the old system to the new.
Advantage:-
 Appropriate when problems or the failure of the system can have
major impact.
 Before switching, outputs of both systems are compared.
 Provides confidence that the new system is functioning and
performing properly before relying on it entirely.
Disadvantage:-
 Users will probably have to enter data into both systems and even
be responsible for comparing the outputs.
 The extra workload and overtime hours may begin to take their toll
and pressure for the project team to "get on with it" may create a stressful environment
for everyone involved.

3. Phased:-
The system is introduced in modules or in different parts of organization
incrementally.
Advantage:-
 Appropriate when introducing a software system to different areas of organization.
 Upgrade on a department-by-department basis.
 A target date for each department would be set to allow each department to plan for the
upgrade accordingly.
 Allow the project team to learn from its experiences during the initial implementation so
that later implementations run more smoothly.
 May be less risky and much more manageable.
Disadvantage:-
Overly optimistic target dates or problems experienced during the early phases of
implementation may create a chain reaction that pushes back the scheduled dates of the
remaining planned implementations.

57 | P a g e