Management of

Computer System
Performance

Chapter 13
Evaluation and Project Management
Evaluation and Project Management
 Agenda:
 Project Planning
 Understanding Cost Components
 Estimating the Project
 Project Control
 Objective:
 Students should be able: to show the
approaches applied in evaluation and project
management .
2
Understanding Cost
Components
 Costs are usually divided into two elements.
Direct and Indirect.
 Specific allocations are a function of Accounting
Practices and may differ.
 Direct Costs-Labor, Materials, Facilities,
Services and Supervision
 Indirect Costs-Administration, Fringe, G&A, Sr.
Management. Etc.

3
Projects & Project
Management
 The following are some basic characteristics of a
Project.
 Specific objectives – defines concisely what you are trying
to do and what you will deliver….in detail. This will be to
solve some problem or set of problems.
 Schedule – define specifically the duration of the effort
 Budget – Identify what is the budget and all variables that
will affect it.
 It should also include what you can and cannot control.
 Resources – Identify who will do the work and
commitments that those resources will be available.
 One-time rather than ongoing

4
Who are the Project Players?
 The Sponsor – The individual who has requested that
the project be undertaken. They usually get or
provide the funding and face the executives.
 (Remember the golden rule: he who has the gold, rules)
 The Stakeholders – Those who are affected by the
project and its implementation,
 The Project Manager – The individual responsible for
the management of the project.
 Project Team – The grunts. Individuals tasked to
perform the work identified in the project plan.
 Bystanders – Those who provide unwanted advice.

5
 Characteristics of a Project

 Sequence or phases of activities

 Unique (Non-repetitive)
 Simple and/or Complex
 Inter-related activities
 Specific Goal
 Specific Time-frame
 Specified Budget
 Defined Specifications

6
Project Stages
Scope Definition –
Requirements & Business Analysis Planning

Fe
Planning – Involves creating detailed,

ed
ba
ck
step by step plans
Scope Feedback
Execution – Definition Execution

Execute the plan and only the plan.

Feedback Loops – During the Execution,
Closure
as problems come up, take the issues back
to the scope and planning stages as needed.
Closure –
Project review with a detailed lessons learned.
7
Leading Contributors to
Project Success
 Formal guidelines
 Accountable sponsors
 Project management skills
 Measurement systems
 Formal priorities
 Regular communication
 Clear tracking
 Automated tools

8
 Why Projects Fail

 Lack of Scope Control

 Poor requirements Definition

 Schedule/Cost overruns

9
 Time & Charge Numbers
 Project time accounting is begun before
requirements development begins.
 In every project in most companies, each has its
own budget.
 Control and protect that budget.
 The most efficient way to do this is through the use if
real time accounting data. As people charge the
account, identify who and what they are doing.
 As projects grow or become more complex, this
becomes a problem.

10
Importance of Estimates
 Estimates are created using the following three
variables.
 Effort or Labor - This ensures that appropriate resources
are provided to the project.
 Time - Establishes an expectation to allow team members
to budget their time. This is also used to calculate cost
elements such as cost of capital and carrying costs.
 Cost - Enables benefits to be weighed against costs. This
is used as one of the key components of project valuation.

11
Identifying Estimating Issues
 Supportive data in the form of time and cost
standards.
 The Basis of Estimate is a useful tool.
 Reasonability based on experience
 Definition of resource requirements for each
activity
 Influencing factors other than time and cost
 Contingency plan estimates

12
IT Project Management - WBS
 Examples:
GOAL Function 1
Goal = e-business site
 Function 1-Storyboards Task 1.1
 1.1 Create layout Template
 1.2 Select Color Scheme Task 1.2
 1.3 Identify threads
Task 1.3
 Function 2 – Site System
Design
Function 2
 2.1 Identify Static Pages
 2.2 Identify Dynamic Pages Task 2.1
 2.3 Identify Dynamic
content templates Task 2.2
 Function 3 - ……
Task 2.3
13
Importance of Scheduling
 Role of project schedule
 Coordinate tasks with non-project activities.
 Acquiring or committing capital
 Coordinate a project’s task activities.
 Assign resources over time.
 Identify schedule and resource issues.
 Identify potential problems.

14
Planning Tools and Techniques
 Gantt Chart: Popularized by Henry Gantt in
the early 1900’s.
 Simple to construct,
 Communicates resources and tasks well.
 PERT Chart: Program Evaluation and
Review Technique - Invented by US Navy in
1958,
 More complex to construct,
 Clearly shows relationships between tasks,
 Show a more complete picture of the project.
15
Schedule Components
 Planned start and expected finish dates for all
phases
 Major milestones and/or key events
 Related reports
 Dependencies and the sequence of activities
 There are three ways to present information visually.
These are:
 The Calendar
 The Gantt chart
 The PERT/CPM (Arrow) chart

16
Calendar

17
Gantt

18
Gantt Chart - Types of Task
Relationships

TASK A
FINISH TO START
TASK B

TASK A
LEAD
TASK B TIME

TASK A
TASK B
LAG TIME

19
PERT/CPM (Arrow)

20
The Critical Path
 For any presentation of a project schedule, the one
element that requires clear and concise definition is
the Critical Path.
 The Critical Path is a sequence of activities that
drive the completion date.
 Late critical path activity equals late project
completion.
 Identify critical path activities early and monitor
closely.
 Create prevention and contingency plans.
 Monitor activities that could enter the critical path.

21
Project Schedule Critical Path
 The critical path is a sequence of Tasks
(WBS elements) that drive the completion
date.
 Most critical path element have little, if any,
slack time. It must be completed sequentially
and on schedule.
 If the critical Task path element is late, the project
will be late.

22
Project Schedule Critical Path
 The management of a project’s critical
path is critical. It is strongly suggested
that you, as the Project Manager;
 Identify critical path activities early and monitor
closely.
 Create prevention and contingency plans.
 Monitor activities that could enter the critical
path.

23
Project Schedules
 Role of project schedule
 Coordinate tasks with non-project related activities.
 Coordinate a project’s task activities.
 Assign resources over time.
 Identify schedule and resource issues.
 Identify potential problems.
 Planned start and expected finish dates for all
phases.
 Major milestones and/or key events.
 Related reports.
 Dependencies and the sequence of activities.

24
Creating a Bottom-Up Budget
 This, as the title implies, requires that each element
within the Project be priced.
 Determine how, at what rate, and when monetary
resources will be applied to a project. This is a cost
of capital approach and is critical to the
management of the budget.
 Demonstrate whether you can meet the top-down
budget developed during the scope phase.

25
Risk and Variance
 The difference between the initial project budget and
the actual spending on the project is variance.
 Causes of budget variance
 Accuracy of estimates – this is usually the biggest issue.
Errors are made when getting aggressive to win the job.
 Inflation – Lately, this has been in check. Labor inflation is
a potential problem.
 Availability of resources – Try to get a WebSphere
Programmer.
 Use of overtime and Seasonal fluctuations in prices – if not
accounted, can trash a budget.

26
 Project Planning
Keys to Failure
 Unplanned Schedule Delays are a major factor in
project failures.
 Many Project Managers fail to allow for any slack in any
portion of the schedule, essentially placing everything on
the critical path. This is sure to result in conflicts.
 Pre-mature Estimates - too precise with out the
 Project Schedule Not Adjusted as Scope Changes
 Failure to recognize Schedule Dependencies
 Project Falls prone to the “Mythical Man-month
theory - [Brooks]

27
Risk Management

 All Projects must have a risk management

process in place. This must include risk
mitigation.
 This approach is to identify critical paths through
the project’s life and to identify various issues
associated with each path.
 Issues are weighted and those with the greatest
probability of occurrence are mitigated with
alternative plans. 

28
IT Project Risk Management

 Risk is inherent in every project.

 Risk is a fundamental ingredient of opportunity.
 It is inherent in every project.
 It is the possibility, not the certainty, of bearing
a loss that must be addressed.
 Loss could be anything from diminished
quality of an end product to increased
cost, missed deadlines, or project failure.

29
IT Project Risk Management
 Risk is neither intrinsically good nor bad.
 Risk is not something to avoid, especially because is
inherent in every project. It is to be mitigated.
 Most risk mitigation methodologies consider risk as the
basis for opportunity.
 The manner in which the risk is mitigated may be the
professional differentiator between your project solution
and that of your competitor.
 As such, risk in itself, risk is neither essentially good
nor bad.

30
IT Project Risk Management

 Risk is not something to fear, but

something to manage.
 Successful teams deal with risk by recognizing
and minimizing uncertainty
 They do this by proactively and aggressively
addressing each identified risk area and
developing a mitigation for it..

31
IT Project Risk Management
 Assess risks continuously throughout the project
life cycle. Successful risk management is more
than just identifying risk factors at the start of the
project;
 Risk must be addressed and a constant assessment of
risk throughout the life of the project must be
undertaken.
 New risks are revealed during the life of a project and
work continues
 Previously identified risks change. They become
either;
 more or less probable or more or less severe.

32
IT Project Risk Management
 Ongoing risk management of a project introduces a
degree of resilience to change.
 Proactive risk management involves identifying
risks ahead of time and preventing them through
reduction, transference, or avoidance.
 Reduce the risk. Risk reduction tries
 to minimize the likelihood that a risk will occur or,
 to minimize the impact if the risk does occur.
 Ex: architecting a system with strong system security
so that the risk of data loss or corruption is reduced.
 Ex. minimizing the impact of a risk is installing an
uninterruptible power supply to your hardware.     
33
IT Project Risk Management
 Transfer the Risk. (this does not refer to giving it to the new PM
when you leave.)
 Risk transference reduces overall risk by ensuring that it is
handled by the most competent party.
 Ex: when a company contracts with a third-party firm to
deploy software, the customer determines that contracting
with an outside entity will result in fewer and less severe
risks than if the customer’s own people were to do it.
 A company may also transfer a risk by transferring the
consequences.
 Ex. A company may have offsite data backup and storage.
 Ex: A company might choose to have an application-
hosting provider host its critical functionality in a more
secure or proven environment.
34
IT Project Risk Management
 Avoid the risk.
 Risk avoidance tries to eliminate the risk by doing
something less risky. Selecting an alternative.
 In the worst case this may involve canceling a project,
but in other cases it could involve sacrificing some
functional requirements to allow adoption of a
packaged solution or avoiding unproven technology.
 Ex: instead of creating open Internet access for a Web-
based application, the company might choose to build a
virtual private network to provide greater security.
 Note: Canceling a project, from a business perspective
may, be the correct solution.

35
The IT Risk
Management Process
 The process for Risk Management addresses the
following elements:
 Identify risks and quantify potential damages.
 Determine and document risks likely to affect the
project.
 Perform on a regular basis.
 Use strategies to reduce potential impact.
 Address both internal and external risks.
 This is done from both a Top down and Bottoms
up perspective.

36
Risk and Budget Contingency
 Management reserve
 Budget to accommodate risks
 Manage to achieve the expected value
 Allocate time and money at expected value
 This is easier said than done. Maintaining a
management reserve is usually difficult. It is one of
the first things to go when a contract is bid
competitively. For internal projects, there remains
hope.

37
Question ?

38
Homework

39