IT Project Management – III BCA Unit -III

CHAPTER 6
THE WORK BREAKDOWN STRUCTURE & ESTIMATION
What is a Work breakdown structure?
The WBS represents a logical decomposition of the work to be performed and focuses on how
the product, service, or result is naturally subdivided. It is an outline of what work is to be
performed.
What is a work package?
The WBS decomposes, or subdivides, the project into smaller components and more manageable
units of work called work packages. A work package may be viewed as a hierarchy that starts
with the project itself. The project is then decomposed into phases, with each phase having one
or more deliverables as defined in the deliverable definition table and deliverable structure chart.

What is a Deliverable?
Deliverables are Tangible, verifiable work products such as Reports, presentations, prototypes, etc .

What is Milestone?
A milestone is a significant event or achievement that provides evidence that that deliverable has been
completed or that a phase is formally over.
Developing the WBS
 The WBS Should Be Deliverable-Oriented
 The WBS Should Support the Project's MOV
o Ensure WBS allows for the delivery of all the project’s deliverables as defined in project
scope
o 100 percent rule
 The Level of Detail Should Support Planning and Control
 Developing the WBS Should Involve the People Who Will Be Doing the Work
 Learning Cycles and Lessons Learned Can Support the Development of a WBS
Explain Project Estimation Techniques – Project Management Approach (6 or 10 marks)
1. Guesstimating
2. Delphi Technique
3. Time Boxing
4. Top-Down
5. Bottom Up
6. Analogous Estimates (Past experiences)
7. Parametric Modeling (Statistical)
1. Guesstimating - Estimation by guessing or just picking numbers out of the air is not the best
way to derive a project’s schedule and budget. Unfortunately, many inexperienced project
managers tend to guesstimate, or guess at the estimates, because it is quick and easy. The
problem is that guessing at the estimates is based on feelings rather than hard evidence.
2. The Delphi technique - This approach involves multiple experts who arrive at a consensus
after a series of round-robin sessions in which information and opinions are anonymously
provided to each expert.

Dr. J. Hannah Monisha, Department of Computer Science Page 1

 IT Project Management – III BCA Unit -III

3. Time-boxing - A technique where a box of time is allocated to a specific task. For example,
a team may be given two weeks (and only two weeks) to develop a prototype of a user
interface.
4. Top-down estimating - This system involves estimating a schedule or budget based upon
how long the project or an activity should take or how much it should cost. For example, the
project manager may be told that the project must be completed in six months. The project
manager then schedules or estimates the project and activities backwards so that the total
duration of the activities adds up to six months or less. Although this approach may be used
when competitive necessity is an issue, unrealistic expectations can lead to projects with very
little chance of meeting their objectives.
5. Bottom-up estimating - Most real-world estimating uses this approach. The WBS outlines
the activities that must be completed, and an estimate is made for each of the activities. The
various durations are then added together to determine the total duration of the project.
Estimates may be analogous to other projects or based on previous experience. These
estimates are also a function of the activity itself (degree of complexity, structuredness, etc.),
the resources assigned (a person’s knowledge, expertise, enthusiasm, etc.) and support
(technology, tools, work environment, etc.).
6. Analogous estimating – It is based on similarity between current projects and others. We
can use information from previous, similar projects as a basis for estimation
7. Parametric Modeling – This technique use project characteristics (parameters) in a
mathematical model to estimate
Example: Estimating Rs.50 per Line Of Code based on: Programming language, Level of
expertise, Size & complexity

Project Estimation Techniques - Software Engineering Metrics and Approaches

1. Lines of code (LOC)—Although counting or trying to estimate the amount of code that must be
written may appear intuitively pleasing, there are a number of deficiencies with this approach. The
number of LOC may provide an idea of the size of a project, but it does not consider the complexity,
constraints, or influencers that must be taken into account.
2. Function points—Function points were introduced by Allen Albrecht of IBM in 1979. They are
synthetic measures that take into account the functionality and complexity of software. Because
function points are independent of the technology or programming language used, one application
system can be compared with another.
3. COCOMO—The COnstructive COst Model was introduced by Barry Boehm in 1981. Estimates for a
software systems effort are determined by an equation based on the project’s complexity. More
specifically, a software project may be classified as organic (relatively simple and straightforward),
embedded (difficult), or semi-detached (somewhere in the middle). Once the effort, in terms of
person-months, is calculated, a similar procedure using another model can estimate the project’s
duration.
4. Heuristics—Heuristics are rules of thumb that are applied to estimating a software project. The basic
premise is that the same activities will be repeated on most projects. This approach may include
assigning a specific percentage of the project schedule to specific activities or using other metrics
such as function points. Estimating the effort and duration of an IT project is not an exact science. No
single method or technique will provide 100 percent accuracy. Using a combination of approaches
may help triangulate an estimate, which provides a confidence greater than when merely guessing or
using a single estimation technique. To be realistic, estimates should be revised as understanding of
the project increases and new information is acquired.

Dr. J. Hannah Monisha, Department of Computer Science Page 2

 IT Project Management – III BCA Unit -III

CHAPTER 7
THE PROJECT SCHEDULE AND BUDGET
Developing the Project Schedule (6/10 marks)
Project Management Tools
1. Gantt Charts
2. Project Network Diagrams
a. Activity on the Node (AON)
b. Critical Path Analysis
c. Program Evaluation and Review Technique (PERT)
d. Precedence Diagramming Method (PDM)

1. Gantt Chart - Henry L. Gantt developed a visual representation that compares a project’s planned
activities with actual progress over time. They are one of the most useful and widely used project
management tools. Gantt chart can be used for planning. Estimates for the tasks or activities defined
in the WBS are represented using a bar across a horizontal time axis. Other symbols, for example,
diamonds, can represent milestones to make the Gantt chart more useful.

The Gantt Chart above depicts the general sequence of activities or work tasks. In this project example,
there are five tasks of varying durations and the project should be completed in 15 time periods (e.g.,
days). In addition, the two shaded diamonds following tasks C and E indicate milestone events.
Gantt charts can also be useful for tracking and monitoring the progress of a project; completed tasks can
be shaded or filled in, and one can get an accurate picture of where the project stands for a given status or
reporting date. In Figure above A and B have been completed, but it looks like Task C is somewhat
behind schedule. Although Gantt charts are simple, straightforward, and useful for communicating the
project’s status, they do not show the explicit relationships among tasks or activities.

2. Project Network Diagrams

Project network diagrams include several useful tools for planning, scheduling, and monitoring the
project’s progress. Similar to Gantt charts, project network diagrams use the WBS as a basis to provide a
visual representation of the workflow of activities and tasks. However, project network diagrams also
provide valuable information about the logical sequence and dependencies among the various activities or
tasks. Subsequently, a completion date or project deadline should be developed based on the estimating
process. The project network diagrams must provide information concerning when specific tasks must
start and finish, and what activities may be delayed without affecting the deadline target date.
a) Activity on the Node (AON) An activity or task focuses on producing a specific project
deliverable, generally takes a specific amount of time to complete, and requires resources.
Activity on the node (AON) is a project network diagramming tool that graphically represents all
of the project activities and tasks, as well as their logical sequence and dependencies. Using
AON, activities are represented as boxes (nodes) and arrows indicate precedence and flow. To
construct an AON network diagram, one begins with the activities and tasks that were defined in

Dr. J. Hannah Monisha, Department of Computer Science Page 3

 IT Project Management – III BCA Unit -III

the WBS. Estimates for each activity or task defined in the WBS should have an associated time
estimate. The next step is to determine which activities are predecessors, successors, or parallel.
o Predecessor activities are those activities that must be completed before another activity
can be started.
o Successor activities are activities that must follow a particular activity in some type of
sequence.
o A parallel activity is an activity or task that can be worked on at the same time as another
activity. Parallel activities may be thought of as an opportunity to shorten the project
schedule; however, they also can be a trade-off since doing more than one thing at the
same time can have a critical impact on project resources.
Activity Duration Predecessor
START 1 -
A 2 START
B 3 START
C 4 A
D 5 A,B
END 6 C,D
b) Critical Path Analysis- The critical path is the longest path in
the project network and is also the shortest time in which the project can be completed.
Identifying the critical path is a major concern to the project manager because any change in the
duration of the activities or tasks on the critical path will affect the project’s schedule.

Possible Path Path Total

Path 1 Start-A-C-End 1+2+4+6 =13
Path 2 Start-A-D-End 1+2+5+6=14
Path 3 Start-B-D-End 1+3+5+6 = 15

The longest path in the AON network diagram is 15 days. This number is significant for two
reasons. First, this tells us that our project is estimated to take 15 days (i.e., the project deadline
will be 15 days after the project starts). Second, and perhaps more importantly, Path 3 is also our
critical path.
c) PERT - The program evaluation and review technique (PERT) was developed in the late
1950s to help manage the Polaris submarine project. At about the same time, the critical path
method (CPM) was developed. The two methods are often combined and called PERT/CPM.
PERT uses the project network diagramming technique to create a visual representation of the
scheduled activities that expresses both their logical sequence and interrelationships. PERT also
uses a statistical distribution that provides probability for estimating when the project and its
associated activities will be completed. This probabilistic estimate is derived by using three
estimates for each activity: optimistic, most likely, and pessimistic. An optimistic estimate is the
minimum time in which an activity or task can be completed. A most likely estimate, as the name
implies, is the normally expected time required to complete the task or activity. A pessimistic
estimate is a worst-case scenario and is viewed as the maximum time in which an activity can or
should be completed.

Dr. J. Hannah Monisha, Department of Computer Science Page 4

 IT Project Management – III BCA Unit -III

d) Precedence Diagramming Method (PDM)- Another tool that is useful for understanding the
relationships among project activities is the precedence diagramming method (PDM). This tool
is similar to the AON project diagram technique and is based on four fundamental relationships.
 Finish-to-start (FS)—A finish-to-start relationship is the most common relationship between
activities and implies a logical sequence. Here, activity or task B cannot begin until task A is
completed. For example, a program is tested after it is written
 Start-to-start (SS)— A start-to-start relationship between tasks or activities occurs when two
tasks can or must start at the same time. Although the tasks start at the same time, they do not
have to finish together—that is, the tasks can have different durations. A start-to-start
relationship would be one type of parallel activity that can shorten a project schedule.
 Finish-to-finish (FF)— Another type of parallel activity is the finish-to-finish relationship.
Here, two activities can start at different times, have different durations, but are planned to be
competed at the same time. Once both of the FF activities are completed, the next activity or
set of activities can be started, or if no more activities follow, the project is complete.
 Start-to-finish (SF)—The start-to-finish relationship is probably the least common and can be
easily confused with the finish-to-start relationship. An example of an SF relationship in real
life might be a nurse working at a hospital. This person may have to work until relieved by
another nurse who arrives to start the next shift.
What are Lead and Lag times?
Lead is starting the next task before the first task is complete. Example: Begin installing the operating
systems when half of the PCs are set up
Lag is the adding of a buffer of time before the next task begins Example: Once the walls have been
painted, wait one day before laying the carpet so that the walls have had a chance to dry.

Developing a Project Budget

The main functions involved in defining a Project Budget are
 Define what resources will be needed to perform the work
 Determine the quantity of resources that are needed
 Define the cost of using each resource
 Calculate the cost of the task or activity
 Ensure that the resources are leveled, that is, resources have not been over allocated assigned to
more than one task scheduled at the same time
In general, if a project uses a resource, the cost associated with that resource must be included in the
project’s budget and must be accounted for as a cost to the project. Project costs are both directly and
indirectly related to the resources needed to complete a particular task or activity or support other
resources that do. It is important that the right resources and the right quantity of resources be
assigned to the project activities.
To determine the total project’s budget, we need to include other costs as well. These costs include:
1. Direct Costs - The direct cost of labor or other resources
2. Indirect Costs - The cost for covering such things as rent, utilities, insurance, etc.
3. Sunk Costs - Costs incurred prior to the project such as a project that has been restarted after a
failed attempt
4. Learning Curve – We often have to “Build one and throw it away” to understand a problem or a
new technology
5. Prorated Costs - The idea that there is a cost associated with using a resource
6. Reserves - Contingency funds to be used at the discretion of the project manager

Dr. J. Hannah Monisha, Department of Computer Science Page 5

 IT Project Management – III BCA Unit -III

CHAPTER 8
MANAGING PROJECT RISK
Effective and Successful Project Risk Management requires:
■ Commitment by all stakeholders
■ Stakeholder responsibility
■ Different risks for different types of projects
The Risk management processes include:
■ Plan Risk Management—Determining how to approach and plan the project risk management activities.
An output of this process is the development of a risk management plan.
■ Identify Risks—Deciding which risks can impact the project. Risk identification generally includes
many of the project stakeholders and requires an understanding of the project’s goal, as well as the
project’s scope, schedule, budget, and quality objectives.
■ Perform Qualitative Risk Analysis—Focusing on a qualitative analysis concerning the impact and
likelihood of the risks that were identified.
■ Perform Quantitative Risk Analysis—Using a quantitative approach for developing a probabilistic
model for understanding and responding to the risks identified.
■ Plan Risk Responses—Developing procedures and techniques to reduce the threats of risks, while
enhancing the likelihood of opportunities.
■ Monitor and Control Risks—Providing an early warning system to monitor identified risks and any new
risks. This system ensures that risk responses have been implemented as planned and had the effect as
intended.
IT PROJECT RISK MANAGEMENT PLANNING PROCESS
Define project risk: (2 marks)
An uncertain event or condition that, if it occurs, has a positive or negative effect on the project
objectives.
Define project risk management (2 marks)
Project risk management includes the processes of conducting risk management planning, identification,
analysis, response planning, and monitoring and control on a project; most of these processes are updated
throughout the project. The objectives of Project Risk Management are to increase the probability and
impact of positive events, and decrease the probability and impact of events adverse to the project.
IT Project Risk Management Processes (6/10 marks)
1. Risk Planning
Risk planning is the first step and begins with having a firm commitment to the entire risk management
approach from all project stakeholders. This commitment ensures that adequate resources will be in place
to plan properly for and manage the various risks of the IT project. These resources may include time,
people, and technology. Stakeholders also must be committed to the process of identifying, analyzing, and
responding to threats and opportunities. It is important that resources, processes, and tools be in place to
adequately plan the activities for project risk management. Systematic preparation and planning can help
minimize adverse effects on the project while taking advantage of opportunities as they arise.
2. Risk Identification
Once commitment has been obtained and preparations have been made, the next step entails identifying
the various risks to the project. Both threats and opportunities must be identified. When identifying
threats to a project, they must be identified clearly so that the true problem, not just a symptom, is
addressed. Moreover, the causes and effects of each risk must be understood so that effective strategies
and responses can be made. A framework for understanding the sources and nature of IT project risks will
be introduced in the next section; however, it is important to keep in mind that project risks are rarely
isolated. Risks tend to be interrelated and affect the project and its stakeholders differently.
3. Risk Assessment
Once the project risks have been identified and their causes and effects understood, the next step requires
that we analyze these risks. Answers to two basic questions are required: What is the likelihood of a
particular risk occurring? What is the impact on the project if it does occur? Risk assessment provides a

Dr. J. Hannah Monisha, Department of Computer Science Page 6

 IT Project Management – III BCA Unit -III

basis for understanding how to deal with project risks. To answer the two questions, qualitative and
quantitative approaches can be used. Several tools and techniques for each approach will be introduced
later. Assessing these risks helps the project manager and other stakeholders prioritize and formulate
responses to those risks that provide the greatest threat or opportunity to the project.
4. Strategies
The next step of the risk planning process is to determine how to deal with the various project risks. In
addition to resource constraints, an appropriate strategy will be determined by the project stakeholders’
perceptions of risk and their willingness to take on a particular risk. Essentially, a project risk strategy
will focus on one of the following for negative risks or threats:
■ Accept or ignore the risk.
■ Avoid the risk completely.
■ Reduce the likelihood or impact of the risk (or both) if the risk occurs.
■ Transfer the risk to someone else (i.e., insurance).
Approaches for positive risks or opportunities may include:
■ Exploitation
■ Sharing ownership
■ Enhancement of the probability of the impact or probability of the positive event
■ Accept and take advantage
5. Risk Monitoring and Control
Once the salient project risks have been identified and appropriate responses formulated, the next step
entails scanning the project environment so that both identified and unidentified threats and opportunities
can be followed, much like a radar screen follows ships. Risk owners should monitor the various risk
triggers so that well informed decisions and appropriate actions can take place.
Monitoring Methods are:
Risk audits—A knowledgeable manager or group can be useful for auditing the project team from time to
time. The audit should focus on ensuring that the project manager and team have done a good job of
identifying and analyzing project risks and on ensuring that proper procedures and processes are in place.
Risk audits should be conducted by people outside the project team. Using outsiders provides a fresh
perspective; the project team may be too close to the project and miss significant threats or opportunities.
■ Risk reviews—Risk audits should be conducted by individuals outside the project team; but risk reviews
can be conducted internally. Throughout the project life cycle, the project stakeholders should hold
scheduled, periodic risk reviews. These reviews should be part of each team meeting and part of the
project team’s learning cycles.
■ Risk status meetings and reports
6. Risk Response
Risk monitoring and control provide a mechanism for scanning the project environment for risks, but the
risk owner must commit resources and take action once a risk threat or opportunity is made known. This
action normally follows the planned risk strategy.
7. Risk Evaluation
Responses to risks and the experience gained provide keys to learning. A formal and documented
evaluation of a risk episode provides the basis for lessons learned and lays the foundation for identifying
best practices. This evaluation should consider the entire risk management process from planning through
evaluation. It should focus on the following questions:
■ How did we do?
■ What can we do better next time?
■ What lessons did we learn?
■ What best practices can be incorporated in the risk management process?

Detailed note on Identifying Project Risk(6 marks)

At the core of the IT project risk framework is the MOV, or measurable organizational value. The MOV
is the goal of the project that defines the measurable value the organization expects from the project. It is

Dr. J. Hannah Monisha, Department of Computer Science Page 7

 IT Project Management – III BCA Unit -III

both a measure and definition of project success. The next layer of the framework includes the project
objectives in terms of scope, quality, schedule, and budget. Although these objectives are not by
themselves sufficient conditions for success, together they do play a critical role in supporting the MOV.
The third layer focuses on the sources of IT project risk. Risks can arise as a result of the various people
or stakeholders associated with a project, legal considerations, the processes (project and product), the
environment, the technology, the organization, the product, and a catchall category called other.
The next layer focuses on whether the sources of
risk are internal or external to the project. It is
important to make this distinction because a
project manager is responsible and accountable
for all project risks internal to the project. For
example, if a project team member is not
adequately trained to use a particular technology,
then the project’s objectives—scope, schedule,
budget, and quality—may be impacted. In turn,
this lack of training may inhibit the project from
achieving its goal or MOV. Once this project risk
has been identified along with its impact, the
project manager can avoid or mitigate the risk by
sending this particular project team member to
training or by assigning certain critical tasks to a
more experienced or skillful team member. On
the other hand, a project manager may not be
responsible for external risks.
The fifth layer of the IT project risk management framework includes three different types of risks:
known risks, known-unknown risks, and unknown-unknown risks.
The outer layer provides a time element in terms of the project life cycle. It may help us determine or
identify when risks may occur, but remind us that they may change over the life of the project.

Other Tools and Techniques

Identifying risks is not always easy. Risks tend to be interrelated and identifying each and every risk may
not be possible or economically feasible. People may not want to admit that potential problems are
possible for fear of appearing incompetent. As a result, stakeholders may deny or downplay a particular
risk. Still, people and organizations have different tolerances for risk, and what may be considered a
normal risk for one stakeholder or organization may be a real concern for another. So, the stakeholders
may concentrate on a particular risk (that may or may not occur) at the expense of other risks that could
have the same impact on the project. It is, therefore, important that the project manager and team guide
the risk management process. Risk identification should include the project team and other stakeholders
who are familiar with the project’s goal and objectives. Using one or more of the following tools, the IT
project risk framework introduced earlier in this section can provide direction for identifying the threats
and opportunities associated with the project:
■ Learning cycles
■ Brainstorming
■ Nominal group technique (NGT)
■ Delphi technique
■ Risk Checklist
✓ Funding for the project has been secured.
✓ Funding for the project is sufficient.
✓ Funding for the project has been approved by senior management.
✓ The project team has the requisite skills to complete the project.
✓ The project has adequate manpower to complete the project.

Dr. J. Hannah Monisha, Department of Computer Science Page 8

 IT Project Management – III BCA Unit -III

✓ The project charter and project plan have been approved by senior management or the project sponsor.
✓ The project’s goal is realistic and achievable.
✓ The project’s schedule is realistic and achievable.
✓ The project’s scope has been clearly defined.
✓ Processes for scope changes have been clearly defined.
■ Interviewing
■ SWOT analysis—SWOT stands for Strengths, Weaknesses, Opportunities, and Threats. The usefulness
of using SWOT analysis is that it allows the project team to identify threats and opportunities as well as
their nature in terms of project or organizational strengths and weaknesses.
■ Cause-and-effect diagrams—The most widely known and used cause-and-effect diagram is the
Fishbone. The diagram can also be used for understanding the causes or factors of a particular risk, as
well as its effects. This technique itself can be used individually or in groups by taking the following
steps:
a. Identify the risk in terms of a threat or opportunity.
b. Identify the main factors that can cause the risk to occur.
c. Identify detailed factors for each of the main factors.
d. Continue refining the diagram until satisfied that the diagram is complete.
■ Past projects - The usefulness of these lessons takes time and a commitment by the organization and
project team to develop a base of knowledge from past projects. The value of this knowledge base will
increase as the base does, allowing project teams to learn from the mistakes and successes of others.
Qualitative Approaches
Qualitative risk analysis focuses on a subjective analysis of risks based upon a project stakeholder’s
experience or judgment. Although the techniques for analyzing project risk qualitatively can be conducted
by individual stakeholders, it may be more effective if done by a group. This group process allows each
stakeholder to hear other points of view and supports open communication among the various
stakeholders. As a result, a broader view of the threats, opportunities, issues, and points of view can be
discussed and understood.
 Expected Value
 Decision Trees
 Risk Impact Table
Quantitative Approaches
Quantitative approaches to project risk analysis include mathematical or statistical techniques that allow
us to model a particular risk situation. At the heart of many of these models is the probability distribution.
Probability distributions can be continuous or discrete.
 Discrete Probability Distributions
 Continuous Probability Distributions
o Normal, PERT, Triangular
 Simulations

Dr. J. Hannah Monisha, Department of Computer Science Page 9