MASENO UNIVERSITY

BACHELOR OF SCIENCE IN COMPUTER SCIENCE

YEAR 4 SEMESTER 1
CCS 401: SOFTWARE PROJECT MANAGEMENT
NOTES

Fundamental concepts
Basic concepts of projects
A project is a temporary endeavor undertaken to create a unique product, service, or result.
 Operations are work done to sustain the business.
 A project ends when its objectives have been reached, or the project has been terminated.
 Projects can be large or small and take a short or long time to complete.

Examples of IT Projects
 A help desk or technical worker replaces laptops for a small department.
 A small software development team adds a new feature to an internal software application.
 A college campus upgrades its technology infrastructure to provide wireless Internet access.
 A cross-functional task force in a company decides what software to purchase and how it will be
implemented.
 A television network develops a system to allow viewers to vote for contestants and provide
other feedback on programs.
 A government group develops a system to track child immunizations.

Project Attributes
A project:
 Has a unique purpose
 Is temporary
 Is developed using progressive elaboration
 Requires resources, often from various areas
 Should have a primary customer or sponsor
 The project sponsor usually provides the direction and funding for the project.
 Involves uncertainty.

Project and Program Managers

 Project managers work with project sponsors, project teams, and other people involved in projects
to meet project goals.
 Program: Is group of related projects managed in a coordinated way to obtain benefits and
control not available from managing them individually.
 Program managers oversee programs and often act as bosses for project managers.

1
The Triple Constraint
 Every project is constrained in different ways by its:
 Scope goals: What work will be done?
 Time goals: How long should it take to complete?
 Cost goals: What should it cost?
 It is the project manager’s duty to balance these three often-competing goals.

Project management
Project management is the application of knowledge, skills, tools and techniques to project activities to
meet project requirements.

Project Stakeholders
Stakeholders are the people involved in or affected by project activities.
Stakeholders include:
 Project sponsor
 Project manager
 Project team
 Support staff
 Customers
 Users
 Suppliers
 Opponents to the project

Nine Project Management Knowledge Areas

Knowledge areas describe the key competencies that project managers must develop.
 Four core knowledge areas lead to specific project objectives (scope, time, cost, and quality).
 Four facilitating knowledge areas are the means through which the project objectives are
achieved ( human resources, communication, risk, and procurement management).
 One knowledge area (project integration management) affects and is affected by all of the other
knowledge areas.
 All knowledge areas are important!

Project Management Tools and Techniques

Project management tools and techniques assist project managers and their teams in various aspects of
project management. Specific tools and techniques include:
 Project charters, scope statements, and WBS (scope).
 Gantt charts, network diagrams, critical path analyses, critical chain scheduling (time).
 Cost estimates and earned value management (cost).

2
Project Success Factors

1. Executive support 7. Firm basic requirements

2. User involvement 8. Formal methodology
3. Experienced project manager 9. Reliable estimates
4. Clear business objectives 10. Other criteria, such as small milestones,
5. Minimized scope proper planning, competent staff, and
6. Standard software infrastructure ownership

The Role of the Project Manager

 Job descriptions vary, but mostly include responsibilities such as planning, scheduling,
coordinating, and working with people to achieve project goals.

Fifteen Project Management Job Functions

1. Define scope of project.
2. Identify stakeholders, decision makers, and escalation procedures.
3. Develop detailed task list (work breakdown structures).
4. Estimate time requirements.
5. Develop initial project management flow chart.
6. Identify required resources and budget.
7. Evaluate project requirements.
8. Identify and evaluate risks.
9. Prepare contingency plan.
10. Identify interdependencies.
11. Identify and track critical milestones.
12. Participate in project phase review.
13. Secure needed resources.
14. Manage the change control process.
15. Report project status.

Suggested Skills for Project Managers

Project managers need a wide variety of skills.

They should be comfortable with change, understand the organizations they work in and with, and lead
teams to accomplish project goals.

 Project managers need both “hard” and “soft” skills.

 Hard skills include product knowledge and knowing how to use various project
management tools and techniques.
 Soft skills include being able to work with various types of people.
 Communication skills: Listens, persuades.
 Organizational skills: Plans, sets goals, analyzes.
 Team-building skills: Shows empathy, motivates, promotes team work.
 Leadership skills: Sets examples, provides vision (big picture), delegates, positive, energetic.
 Coping skills: Flexible, creative, patient, persistent.
 Technology skills: Experience, project knowledge.

3
Most Significant Characteristics of Effective and Ineffective Project Managers

Effective Project Managers Ineffective Project Managers

 Leadership by example  Sets bad example
 Visionary  Not self-assured
 Technically competent  Lacks technical expertise
 Decisive  Poor communicator
 Good communicator  Poor motivator
 Good motivator
 Stands up to upper management when
necessary
 Supports team members
 Encourages new ideas

Special nature of software projects

Lack of constraints
 IT projects are not subject to the laws of physics and the associated constraints in the same way
as, for example, civil engineering projects.
 This can produce a perception that anything and everything is possible with IT. Of course, this is
not the case – software is governed by real constraints, but these tend to be multidimensional and
abstract in nature, and therefore difficult to understand and communicate.
 Both customers and suppliers are susceptible to forgetting or simply not understanding the
limitations of software, resulting in unrealistic expectations and over-ambitious projects.
 This has created an impression that software is largely free of constraints and its potential is
therefore unlimited.

Visualization
 Software is effectively invisible. This visualization problem is a source of many potential
software project failures.
 Senior managers commissioning software systems may ask for functions that are over-ambitious,
or even impossible to deliver, without having any sense of the level of complexity entailed in
meeting their request.
 Unlike other branches of engineering, it is quite unusual for senior management to have
significant first-hand experience of software engineering or software project management.
 It is also extremely challenging to represent the key facets of software in a way which is
accessible to all stakeholders, making the specification process potentially fraught.

4
 Many graphical representations are used for software specification, e.g. the Unified Modeling
Language (UML), but these are subject to ambiguities and only deal with limited aspects of the
system.
 A further difficulty associated with the ‘invisibility’ of software occurs during monitoring of the
project.
 The lack of a readily tangible product means that it is very easy for the project to proceed for a
considerable time before problems become apparent, and without it being possible to verify that
the passing of time and expenditure of money correlate with progression of the project in the
desired direction.

Flexibility
 A related problem for software projects, also stemming from the intangible nature of software, is
abuse of the perceived flexibility of software.
 The inability to visualize the boundaries of what is possible or practical in software encourages
people to change their mind more frequently than they might do for engineering projects where
constraints are obvious.
 Excessive requests for new features or alteration of functions etc. during the course of the project
introduce unnecessary and undesirable complexity.
 This contributes to time and budget over-run, thereby increasing the chance of project failure.
 Flexibility is also reflected in the fact that there are generally multiple ways of solving the same
problem in software engineering.

Complexity

 Complexity can be a significant obstacle to successful design and delivery of software projects.
 In software engineering, complexity is both harder to detect and less well understood.
 Complexity in large scale software systems remains an area which is insufficiently well
understood.
 The degree of complexity entailed in achieving a particular objective can be very difficult to
estimate at the project outset.
 As a result, projects may involve much more complexity than was originally realized; such
projects are extremely susceptible to failure or difficulty.

Uncertainty
 Many complex IT systems seek to undertake or augment tasks previously carried out by people.
 There can be great difficulty in elucidating clear requirements for such systems.
 By comparison the task of actually implementing the specified system can be comparatively
straightforward.
 Uncertainty is most likely to occur in meeting non-functional requirements such as security,
scalability or speed of response.

5
Software and failure
 Since software is pure logic, it has no physical degradation mechanisms which can cause it to fail.
In principle, this makes software very attractive – intuitively, once the designers have got it
‘right’, it should work correctly, indefinitely.
 In reality this idealistic state is never achieved and all complex software systems have a
propensity to fail.
 The susceptibility to failure stems from the fact that an infinite number of assumptions are
embedded in every real world piece of software.
 Most of the assumptions are not decisions that have been taken consciously, rather they arise
from things that were not thought about during the development process.
 Unfortunately, the unbounded number of such assumptions means that sooner or later one or
more will prove incorrect, potentially causing the software to fail.
 This feature of software impacts greatly on the way in which software projects must be handled.
Clearly, although some element of the software may fail at some point, it should be possible to
design the system in such a way that failure has no discernible impact on the user.
 The system should also be engineered to facilitate diagnosis of the causes of failures, in turn
enabling improvements to be made to the design.
 Furthermore, it is perfectly possible for software to fail without the project as a whole being
jeopardized if such precautions are taken.
 Regrettably, many projects are undertaken on the assumption that the software will be, or can be
made to be, ‘perfect’.

Supporting change
 The majority of software projects are undertaken to deliver some kind of business or process
change.
 In some cases, software systems will be introduced to enable a major business transformation,
 In other cases they will be automating an existing process.
 Even when the aim is defined as automation, the people involved will need to alter their practices,
so business change in some form will ultimately result.
 As a consequence, software practitioners need – but unfortunately do not always have – an
understanding of the business and the processes concerned if the software system is to achieve the
intended outcome.
 Problems also commonly arise because the description of the business process given to the
supplier does not accurately represent the process being employed.
 In the case of automation systems, the manual process being replaced by the software system may
be intrinsically ineffective – automation is unlikely to make a bad process better, although it may
execute it more quickly!

6
Universal constraints:
These are the main constraints that can cause software project failure if not managed well.
The universal constraints of a software project are: The project scope, time and cost. These
constraints need to be managed well to enable a software project move until successful
completion.

Scope
 Scope refers to all the work involved in creating the products of the project and the processes
used to create them.
 A deliverable is a product produced as part of a project, such as hardware or software, planning
documents, or meeting minutes.
 Project scope management includes the processes involved in defining and controlling what is or
is not included in a project.

Project Scope Management Processes involve

 Scope planning: Deciding how the scope will be defined, verified, and controlled
 Scope definition: Reviewing the project charter and preliminary scope statement and adding
more information as requirements are developed and change requests are approved.
 Creating the WBS: Subdividing the major project deliverables into smaller, more manageable
components.
 Scope verification: Formalizing acceptance of the project scope.
 Scope control: Controlling changes to project scope.

Time
Project time management involves the processes required to ensure timely completion of a project.
Processes include:
 Activity definition
 Activity sequencing
 Activity duration estimating
 Schedule development
 Schedule control

Cost
 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, such as dollars.
 Project cost management includes the processes required to ensure that the project is completed
within an approved budget.

7
Project Cost Management Processes include:
 Cost estimating: Developing an approximation or estimate of the costs of the resources needed to
complete a project.
 Cost budgeting: Allocating the overall cost estimate to individual work items to establish a
baseline for measuring performance.
 Cost control: Controlling changes to the project budget.

Initiation:
The initiation of a project involves determining its requirements to some degree of detail, outlining
candidate solution approaches and an assessment of whether or not to proceed with the project.

Identification of purpose
The purpose of the software project is identified taking by user requirements and business
processes into consideration. The user requirements are then translated into software system
specification in broad terms. Software system specification defines the functions to be performed
by the software in order to achieve the user requirements.

Stakeholders
Stakeholders are the people who are concerned with the software development project. The main
stakeholders include:
 Senior managers: who define the business issues that often have significant influence
on the project
 Project (technical) managers: who must plan, motivate, organize, and control the
practitioners who do software work.
 Practitioners: who deliver the technical skills that are necessary to engineer a product or
application
 Customers: who specify the requirements for the software to be engineered and other
stakeholders who have a peripheral interest in the outcome
 End-users: who interact with the software once it is released for production use

Reaching consensus
After identifying the purpose of the project and the stakeholders, it is now the responsibility of the project
manager to ensure that all the stakeholders reach a consensus on important matters pertaining to the
project. Since software development involves teamwork, the project manager should:
 Concentrate on understanding the problem to be solved
 Manage the flow of ideas and at the same time letting everyone on the Project team (by word or
action) that quality counts and that it will not be compromised.
 Take full charge of the Project
 Have the Confidence to assume Project Control (when necessary)
 Gives assurance to allow good Technical people to follow their instincts

8
 Be able to “read people”, and understand verbal and non-verbal symbols and react to the needs of
the people sending these signals

Determination and Negotiation of Requirements

Having stable and explicit user requirements makes the planning process a lot simpler, since the
information is certain. However, it is more likely that the knowledge of the future process and product
requirements is to a substantial degree uncertain. For example, the determination of initial requirements is
often influenced by market investigations. An analysis of what is already available is relevant to the
feasibility of the project. Market analysis may also inform the requirements negotiation process. Linked to
this is some evaluation of the solution space and a consideration of what is possible. Indeed, numerous
candidate solutions may be considered and these are fed forward to the feasibility analysis.

Given this complicated planning scenario, the software process cannot simply be the process of capturing
fixed requirements that are waiting to be found and then developing an unproblematic and stable
implementation. Rather, it is a creative process where new ideas are generated, existing ideas combined
and often tradeoffs made between the requirements and designs. In such cases, stakeholder collaboration,
requirements negotiation and re-negotiation become a reality. Determination and renegotiation of
requirements, so as to enable the setting of the scope of the project, is therefore necessary at an early
stage.

Feasibility Study

Traditionally, in systems analysis, Feasibility Study has been recommended with the principal aim of
determining if the project is viable and also to get some preliminary planning data. More precisely, the
Feasibility Study usually refers to an assessment of the product/project against technical, operational,
financial and social/political criteria. Such a phase allows the early cancellation of projects with minimal
cost or, if the project proceeds, assists in the estimation of funding required and further planning.

Scope
 Scope refers to all the work involved in creating the products of the project and the processes
used to create them.
 A deliverable is a product produced as part of a project, such as hardware or software, planning
documents, or meeting minutes.
 Project scope management includes the processes involved in defining and controlling what is or
is not included in a project.

Project Scope Management Processes

 Scope planning: Deciding how the scope will be defined, verified, and controlled.
 Scope definition: Reviewing the project charter and preliminary scope statement and adding
more information as requirements are developed and change requests are approved.

9
 Creating the WBS: Subdividing the major project deliverables into smaller, more manageable
components.
 Scope verification: Formalizing acceptance of the project scope.
 Scope control: Controlling changes to project scope.

Scope Planning and the Scope Management Plan

 The scope management plan is a document that includes descriptions of how the team will
prepare the project scope statement, create the WBS, verify completion of the project
deliverables, and control requests for changes to the project scope.
 Key inputs include the project charter, preliminary scope statement, and project management
plan.

Scope Definition and the Project Scope Statement

 The preliminary scope statement, project charter, organizational process assets, and approved
change requests provide a basis for creating the project scope statement.
 As time progresses, the scope of a project should become clearer and more specific.

Creating the Work Breakdown Structure (WBS)

 A WBS is a deliverable-oriented grouping of the work involved in a project that defines the total
scope of the project.
 A WBS is a foundation document that provides the basis for planning and managing project
schedules, costs, resources, and changes.
 Decomposition is subdividing project deliverables into smaller pieces.

Example of WBS: Intranet WBS in Tabular Form

1.0 Concept
1.1 Evaluate current systems
1.2 Define requirements
1.2.1 Define user requirements
1.2.2 Define content requirements
1.2.3 Define system requirements
1.2.4 Define server owner requirements
1.3 Define specific functionality
1.4 Define risks and risk management approach
1.5 Develop project plan
1.6 Brief Web development team
2.0 Web Site Design
3.0 Web Site Development
4.0 Roll Out
5.0 Support

Approaches to Developing WBSs

 Guidelines: Below are some guidelines for preparing WBSs.
 Analogy approach: Review WBSs of similar projects and tailor to your project.

10
 Top-down approach: Start with the largest items of the project and break them down.
 Bottom-up approach: Start with the specific tasks and roll them up.
 Mind-mapping approach: Write tasks in a nonlinear, branching format and then create the WBS
structure.

Sample mind-mapping approach

Building A

Perform physical inventory Building B

Update inventory
Update database
Building C

Project management IT
Acquire hardware and software
Upgrade
project
Desktop
servers

User hardware
Laptops
Install hardware and software

The WBS Dictionary and Scope Baseline

 Many WBS tasks are vague and must be explained in more detail so people know what to do and
can estimate how long the work will take and what it will cost.
 A WBS dictionary is a document that describes detailed information about each WBS item.
 The approved project scope statement and its WBS and WBS dictionary form the scope baseline,
which is used to measure performance in meeting project scope goals.

Advice for Creating a WBS and WBS Dictionary

 A unit of work should appear in only one place in the WBS.
 The work content of a WBS item is the sum of the WBS items below it.
 A WBS item is the responsibility of only one individual, even though many people may be
working on it.
 The WBS must be consistent with the way in which work is actually going to be performed; it
should serve the project team first, and other purposes only if practical.
 Project team members should be involved in developing the WBS to ensure consistency and buy-
in.

11
 Each WBS item must be documented in a WBS dictionary to ensure accurate understanding of
the scope of work that is included and not included in that item.
 The WBS must be a flexible tool to accommodate inevitable changes while properly maintaining
control of the work content in the project according to the scope statement.

Scope Verification
 It is very difficult to create a good scope statement and WBS for a project.
 It is even more difficult to verify project scope and minimize scope changes.
 Many IT projects suffer from scope creep and poor scope

Scope Control
 Scope control involves controlling changes to the project scope.
 Goals of scope control are to:
 Influence the factors that cause scope changes.
 Ensure changes are processed according to procedures developed as part of integrated
change control.
 Manage changes when they occur.
 Variance is the difference between planned and actual performance.

Suggestions for Improving User Input

 Develop a good project selection process and insist that sponsors are from the user organization.
 Place users on the project team in important roles.
 Hold regular meetings with defined agendas, and have users sign off on key deliverables
presented at meetings.
 Deliver something to users and sponsors on a regular basis.
 Don’t promise to deliver when you know you can’t.
 Co-locate users with developers.

Suggestions for Reducing Incomplete and Changing Requirements

 Develop and follow a requirements management process.
 Use techniques such as prototyping, use case modeling, to get more user involvement.
 Put requirements in writing and keep them current.
 Create a requirements management database for documenting and controlling requirements.
 Conduct adequate testing throughout the project life cycle.
 Review changes from a systems perspective.
 Emphasize completion dates to help focus on what’s most important.
 Allocate resources specifically for handling change requests and.

Using Software to Assist in Project Scope Management

 Word-processing software helps create scope-related documents.
 Spreadsheets help perform financial calculations and weighed scoring models, and help develop
charts and graphs.

12
 Communication software, such as e-mail and the Web, helps clarify and communicate scope
information.
 Project management software helps create a WBS, the basis for tasks on a Gantt chart.
 Specialized software is available to assist in project scope management.

Project Time Management

Importance of Project Schedules

 Managers often cite delivering projects on time as one of their biggest challenges
 Time has the least amount of flexibility; it passes no matter what
 Schedule issues are the main reason for conflicts on projects, especially during the second half of
projects

Project Time Management Processes

 Project time management involves the processes required to ensure timely completion of a
project. Processes include:
 Activity definition
 Activity sequencing
 Activity duration estimating
 Schedule development
 Schedule control

Where Do Schedules Come From?

Defining Activities
 Project schedules grow out of the basic document that initiate a project
 Project charter includes start and end dates and budget information
 Scope statement and WBS help define what will be done
 Activity definition involves developing a more detailed WBS and supporting explanations to
understand all the work to be done

Activity Sequencing
 Involves reviewing activities and determining dependencies
 Discretionary dependencies: defined by the project team; soft logic
 Mandatory dependencies: inherent in the nature of the work; hard logic
 External dependencies: involve relationships between project and non-project activities
 You must determine dependencies in order to use critical path analysis

Project Network Diagrams

 Project network diagrams are the preferred technique for showing activity sequencing
 A project network diagram is a schematic display of the logical relationships among, or
sequencing of, project activities

13
Arrow Diagramming Method
• Also called activity-on-arrow (AOA) project network diagrams
• Activities are represented by arrows
• Nodes or circles are the starting and ending points of activities
• Can only show finish-to-start Dependencies

Sample Activity-on-Arrow (AOA) Network Diagram for Project X

D=4
2 5

A=1 E=5 H=6

J=3
3 F=4
1 B=2 8
6

C=3 I=2

G=6
4 7

Note: All durations are in days: A=1 means that activity A has a duration of 1 day

Process for Creating AOA Diagrams

1. Find all of the activities that start at node 1. Draw their finish nodes and draw arrows between
node 1 and those finish nodes. Put the activity letter or name and duration estimate on the
associated arrow
2. Continuing drawing the network diagram, working from left to right. Look for bursts and merges.
 Bursts occur when a single node is followed by two or more activities.
 A merge occurs when two or more nodes precede a single node
3. Continue drawing the project network diagram until all activities are included on the diagram that
have dependencies
4. As a rule of thumb, all arrowheads should face toward the right, and no arrows should cross on an
AOA network diagram

Activity Duration Estimating

 After defining activities and determining their sequence, the next step in time management is
duration estimating
 Duration includes the actual amount of time worked on an activity plus elapsed time
 People doing the work should help create estimates, and an expert should review them

14
Schedule Development
 Schedule development uses results of the other time management processes to determine the start
and end date of the project and its activities
 Ultimate goal is to create a realistic project schedule that provides a basis for monitoring project
progress for the time dimension of the project
 Important tools and techniques include Gantt charts, PERT analysis and critical path analysis

Gantt Charts
 Gantt charts provide a standard format for displaying project schedule information by listing
project activities and their corresponding start and finish dates in a calendar format
 Symbols include:
 A black diamond: milestones or significant events on a project with zero duration
 Thick black bars: summary tasks
 Lighter horizontal bars: tasks
 Arrows: dependencies between tasks

Critical Path Method (CPM)

 CPM is a project network analysis technique used to predict total project duration
 A critical path for a project is the series of activities that determines the earliest time by which the
project can be completed
 The critical path is the longest path through the network diagram and has the least amount of
slack or float

Finding the Critical Path

 First develop a good project network diagram
 Add the durations for all activities on each path through the project network diagram
 The longest path is the critical path

Simple Example of Determining the Critical Path

 Consider the following project network diagram. Assume all times are in days.

4
C=2 E=1
B=5
A=2 2
1 3
6

D=7 F=2
5

a. How many paths are on this network diagram?

15
b. How long is each path?
c. Which is the critical path?
d. What is the shortest amount of time needed to complete this project?

Determining the Critical Path for Project X

D=4
2 5

A=1 E=5 H=6

J=3
3 F=4
1 B=2 8
6

C=3 I=2

G=6
4 7

Note: All durations are in days

Path 1: A-D-H-J Length = 1 + 4 + 6 + 3 = 14 days
Path 2: B-E-H-J Length = 2 + 6 + 5 + 3 = 16 days
Path 3: B-F-J Length = 2 + 4 + 3 = 9 days
Path 4: C-G-I-J Length = 3 + 6 + 2 + 3 = 14 days

Since the critical path is the longest path through the network diagram, Path 2, B-E-
H-J, is the critical path for project X

More on the Critical Path

 If one of more activities on the critical path takes longer than planned, the whole project schedule
will slip unless corrective action is taken
 Clearing Some Misconceptions:
 There can be more than one critical path if the lengths of two or more paths are the same
 The critical path can change as the project Progresses

Using Critical Path Analysis to Make Schedule Trade-offs

16
 Free slack or free float is the amount of time an activity can be delayed without delaying the
early start of any immediately following activities
 Total slack or total float is the amount of time an activity may be delayed from its early start
without delaying the planned project finish date

Free and total float or slack time for Project X

TASK START FINISH LATE START LATE FREE TOTAL

FINISH SLACK SLACK
A 6/2/02 6/2/02 6/4/02 6/4/02 0D 2D
B 6/2/02 6/3/02 6/2/02 6/3/02 0D 0D
C 6/2/02 6/4/02 6/4/02 6/6/02 0D 2D
D 6/3/02 6/6/02 6/5/02 6/10/02 2D 2D
E 6/4/02 6/10/02 6/4/02 6/10/02 0D 0D
F 6/4/02 6/9/02 6/13/02 6/18/02 7D 7D
G 6/5/02 6/12/02 6/9/02 6/16/02 0D 2D
H 6/11/02 6/18/02 6/11/02 6/18/02 0D 0D
I 6/13/02 6/16/02 6/17/02 6/18/02 2D 2D
J 6/19/02 6/23/02 6/19/02 6/23/02 0D 0D

Techniques for Shortening a Project Schedule

 Shortening durations of critical tasks for adding more resources or changing their scope
 Crashing tasks by obtaining the greatest amount of schedule compression for the least
incremental cost
 Fast tracking tasks by doing them in parallel or overlapping them

Importance of Updating Critical Path Data

 It is important to update project schedule information
 The critical path may change as you enter actual start and finish dates
 If you know the project completion date will slip, negotiate with the project sponsor

Program Evaluation and Review Technique (PERT)

 PERT is a network analysis technique used to estimate project duration when there is a high
degree of uncertainty about the individual activity duration estimates
 PERT uses probabilistic time estimates based on using optimistic, most likely, and pessimistic
estimates of activity durations

PERT Formula and Example

PERT weighted average formula = (optimistic time) + 4 × (most likely time) + (pessimistic time)
6

17
Example:
PERT weighted average = 8 workdays + 4 × 10 workdays + 24 workdays = 12 days
6

where 8 = optimistic time, 10 = most likely time, and 24 = pessimistic time

 PERT chart = graphical representation of the scheduling of events in a project

 Sample PERT Chart:

• A PERT chart is a graph

• Edges are tasks/activities that need to be done
• Nodes are the events or milestones
• Task edge T from event node E1 to event node E2 signifies:
• Until event E1 happens, task T cannot be started
• Until task T finishes, event E2 cannot happen
• Events often simply represent completion of tasks associated with arrows entering it

PERT Chart Task Edges

• Parts of a task/activity edge

• Task letter:

18
• Often keyed to a legend to tell which task it represents
• Task duration = how long (e.g. days, hours) task will take

PERT Chart Event Nodes

Steps Building a PERT Chart

1. Make a list of all project tasks (and events if possible).

2. Find interrelated task dependencies (what task has to be completed before other tasks)
3. Draw initial PERT without durations, ECTs or LCTs
4. Estimate duration of each task
5. Fill in durations
6. Calculate ECTs and LCTs

Example: Generic Software Project

19
 To start PERT chart: identify dependencies between tasks

Dummy Tasks
 A dummy task is one whose duration = 0
 It shows the dependency between 2 events where no activity is performed
Example:
• Events 3, 4 signify the compilation of separate modules.
• Create an event 5 to signify “all modules compiled together”.
Denote dummy tasks using dash lines

Example: Tasks with Dependencies

 To start the PERT, identify the dependencies amongst tasks

20
Software Example: Skeleton PERT Chart

PERT Chart with Durations

 Estimated durations of all tasks are in days

 New PERT chart, with durations filled in:
 Dummy tasks (dashed lines) always have a duration of zero

Calculating ECTs
 ECT = earliest time event can be completed
 To calculate ECT:
 For an event not depending on others: ECT = 0
o Usually this is the first event
 For an event E depending on one or more others:
o Calculate ECTs of event(s) that E depends on
o Add duration(s) of task(s) leading to E
o If E depends on more than one event, take MAX

21
 Proceed left to right through the chart

Calculating LCT

LCT = latest time event can be completed, while still finishing last task at indicated time
To calculate LCT:
 For an event which no other events depend on: LCT = ECT
 Generally there will only be one such event
 For an event E which one or more others depend on:
 Calculate LCTs of event(s) that depend on E
 Subtract duration(s) of task(s) leading from E
 If more than one event depends on E, take MINIMUM
Proceed right to left (  ) through PERT chart

22
Critical Path
 Determines the path with the maximum duration to complete the project.
 Path through chart such that if any deadline slips, the final deadline slips (where all events have
ECT = LCT (usually there is only one)
 The critical path for the chart above is: A-B-C-D-H

PERT For Dealing With Uncertainty

 For many situations Research, development, new products and projects, use 3 time estimates
m= most likely time estimate, mode.
a = optimistic time estimate,
b = pessimistic time estimate
 Expected Value (TE) = (a + 4m + b) /6
 Variance (V) = ( ( b – a) / 6 ) 2
 Std Deviation (δ) = SQRT (V)
 The activity is represented on the PERT Chart by Expected value and std Deviation

23
The complete network

Critical Path Analysis (PERT)

Activity LS ES Slacks Critical?

a 0 0 0 Yes

b 1 0 1

c 4 0 4

d 20 20 0 Yes

e 25 20 5

f 29 20 9
g 21 20 1

h 14 10 4

i 25 24 1

j 35 35 0 Yes

Comparison between CPM and PERT

CPM PERT

24
1 Uses network, calculate float or slack, identify Same as CPM
critical path and activities, guides to monitor and
controlling project
2 Uses one value of activity time Requires 3 estimates of activity time
Calculates mean and variance of time
3 Used where times can be estimated with confidence, Used where times cannot be estimated with
familiar activities confidence.
Unfamiliar or new activities
4 Minimizing cost is more important Meeting time target or estimating percent
completion is more important
5 Example: construction projects, building one off Example: Involving new activities or
machines, ships, etc products, research and development etc

BENEFITS OF CPM / PERT NETWORK

It is a consistent framework for planning, scheduling, monitoring, and controlling project that:
 Shows interdependence of all tasks, work packages, and work units.
 Helps proper communications between departments and functions.
 Determines expected project completion date.
 Identifies so-called critical activities, which can delay the project completion time.
 Identified activities with slacks that can be delayed for specified periods without penalty, or from
which resources may be temporarily borrowed
 Determines the dates on which tasks may be started or must be started if the project is to stay in
schedule.
 Shows which tasks must be coordinated to avoid resource or timing conflicts.
 Shows which tasks may run in parallel to meet project completion date

Uses of PERT Charts

PERT charts can be used for:
 Determining the estimated time to complete a project
 Deriving actual project dates
 Allocating resources
 Identifying potential and current problems (is one task behind schedule?, can we shuffle people?)
 Identifying the critical path
 Reallocating resources, e.g. from non-critical to critical tasks.

Controlling Changes to the Project Schedule

 Perform reality checks on schedules
 Allow for contingencies
 Don’t plan for everyone to work at 100% capacity all the time

25
 Hold progress meetings with stakeholders and be clear and honest in communicating schedule
issues

Working with People Issues

 Strong leadership helps projects succeed more than good PERT charts
 Project managers should use
 Empowerment
 Incentives
 Discipline
 negotiation

Using Software to Assist in Time Management

 Software for facilitating communications helps people exchange schedule-related information
 Decision support models help analyze trade-offs that can be made
 Project management software can help in various time management areas

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, such as dollars.
 Project cost management includes the processes required to ensure that the project is completed
within an approved budget.

Project Cost Management Processes

 Cost estimating: Developing an approximation or estimate of the costs of the resources needed to
complete a project.
 Cost budgeting: Allocating the overall cost estimate to individual work items to establish a
baseline for measuring performance.
 Cost control: Controlling changes to the project budget.

Basic Principles of Cost Management

 Most members of an executive board have a better understanding and are more interested in
financial terms than IT terms, so IT project managers must speak their language.
 Profits are revenues minus expenses.
 Life cycle costing considers the Total Cost of Ownership, or development plus support
costs, for a project.

26
 Cash flow analysis determines the estimated annual costs and benefits for a project and
the resulting annual cash flow.
 Tangible costs or benefits are those costs or benefits that an organization can easily measure in
dollars.
 Intangible costs or benefits are costs or benefits that are difficult to measure in monetary terms.
 Direct costs are costs that can be directly related to producing the products and services of the
project.
 Indirect costs are costs that are not directly related to the products or services of the project, but
are indirectly related to performing the project.
 Sunk cost is money that has been spent in the past; when deciding what projects to invest in or
continue, you should not include sunk costs.
 Learning curve theory states that when many items are produced repetitively, the unit cost of
those items decreases in a regular pattern as more units are produced.
 Reserves are dollars included in a cost estimate to mitigate cost risk by allowing for future
situations that are difficult to predict.
 Contingency reserves allow for future situations that may be partially planned for
(sometimes called known unknowns) and are included in the project cost baseline.
 Management reserves allow for future situations that are unpredictable (sometimes
called unknown unknowns).
Cost Estimating
 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.

Types of Cost Estimates

Types of estimate When done Why done How accurate

Rough order of Very early in the project Provides estimate of -25% to +75
magnitude(ROM) life cycle often 3 – 5 cost for selection
years before project decisions
completion
Budgetary Early 1 – 2 years out Puts dollar in the budget -10% to +25%
plan
Definitive Later in the project less Provides details for -5% to +10%
than 1 year out purchases, estimates and
actual costs

Cost Management Plan

 A cost management plan is a document that describes how the organization will manage cost
variances on the project.

27
 A large percentage of total project costs are often labour costs, so project managers must develop
and track estimates for labour.

Cost Estimation Tools and Techniques

Basic tools and techniques for cost estimates:
 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.
 Bottom-up estimates: Involve estimating individual work items or activities and summing them
to get a project total.
 Parametric modeling: Uses project characteristics (parameters) in a mathematical model to
estimate project costs.
 Computerized tools: Tools, such as spreadsheets and project management software, that can
make working with different cost estimates and cost estimation tools easier.

Software Cost Estimation approaches

There are three main approaches to estimation:
 Empirical
 Heuristic
 Analytical

Empirical techniques: an educated guess based on past experience.

Heuristic techniques: assume that the characteristics to be estimated can be expressed in terms of
some mathematical expression.
Analytical techniques: derive the required results starting from certain simple assumptions.

Software Size Metrics

Define the measures used to determine the size of the software. The metrics used are:

 LOC (Lines of Code) metric

 Function Point Metric

LOC (Lines of Code) metric

 Simplest and most widely used metric.
 Comments and blank lines should not be counted.

Disadvantages of Using LOC

 Size can vary with coding style.
 Focuses on coding activity alone.
 Correlates poorly with quality and efficiency of code.
 Penalizes higher level programming languages, code reuse, etc.
 Measures lexical/textual complexity only.
 does not address the issues of structural or logical complexity.

28
 Difficult to estimate LOC from problem description.
 So not useful for project planning

Function Point Metric

Overcomes some of the shortcomings of the LOC metric
 Function points can be: #inputs , #Outputs , #inquiries, #files and #interfaces
 Input: A set of related inputs is counted as one input.
 Output: A set of related outputs is counted as one output.
 Inquiries: Each user query type is counted.
 Files: Files are logically related data and thus can be data structures or physical files.
 Interface: Data transfer to other systems.

A major drawback:
 The size of a function is considered to be independent of its complexity.
.

Empirical Size Estimation Techniques

Expert Judgement:
 An euphemism for guess made by an expert.
 Experts divide a software product into component units:
o e.g. GUI, database module, data communication module, billing module, etc.
 Add up the guesses for each of the components.
 Suffers from individual bias.

Delphi Estimation
 Involves a Team of Experts and a coordinator.
 Experts carry out estimation independently:
o mention the rationale behind their estimation.
o coordinator notes down any extraordinary rationale:
 circulates among experts.
 Experts re-estimate.
 Experts never meet each other to discuss their viewpoints.
 overcomes some of the problems of expert judgement.

Heuristic Estimation Techniques

 Estimates the parameter based on the estimated characteristic and some constant
Single Variable Model:
 The parameter to be estimated depends on one characteristic.
 Parameter to be Estimated=C1(Estimated Characteristic)d1

29
Multivariable Model:
 Assumes that the parameter to be estimated depends on more than one characteristic.
 Parameter to be Estimated=C1(Estimated Characteristic)d1+ C2(Estimated Characteristic)d2+…
 C1, C2, d1, d2are constants for different categories of software products
 Usually more accurate than single variable models.

COCOMO Model
 It is one of the Heuristic Estimation Techniques
 COCOMO (COnstructive COst MOdel) proposed by Boehm.
 Divides software product developments into 3 categories:
 Organic
 Semidetached
 Embedded

COCOMO Product classes

Product classes roughly correspond to:
 Application, utility and system programs respectively.
 Data processing and scientific programs are considered to be application programs.
 Compilers, linkers, editors, etc., are utility programs.
 Operating systems and real-time system programs, etc. are system programs.

Elaboration of Product classes

 Organic: Involves relatively small groups working to develop well-understood applications.
 Semidetached: Involves a Project team that consists of a mixture of experienced and
inexperienced staff.
 Embedded: The software is strongly coupled to complex hardware, or real-time systems.

For each of the three product categories:

 From size estimation (in KLOC), Boehm provides equations to predict:
 project duration in months
 effort in programmer-months
 Boehm obtained these equations:
 Examined historical data collected from a large number of actual projects.

Software cost estimation is done through three stages

 Basic COCOMO,
 Intermediate COCOMO,
 Complete COCOMO.

Basic COCOMO Model

 Gives only an approximate estimation:

30
 Effort = a1 (KLOC)a2
 Tdev = b1 (Effort)b2
o KLOC is the estimated kilo lines of source code,
o a1, a2, b1, b2 are constants for different categories of software products,
o Tdev is the estimated time to develop the software in months,
o Effort estimation is obtained in terms of person months (PMs).

Development Effort Estimation

Organic:
 Effort = 2.4 (KLOC)1.05 PM
Semi-detached:
 Effort = 3.0(KLOC)1.12 PM
Embedded:
 Effort = 3.6 (KLOC)1.20PM

Development Time Estimation

Organic:
 Tdev = 2.5 (Effort)0.38 Months
Semi-detached:
 Tdev = 2.5 (Effort)0.35 Months
Embedded:
 Tdev = 2.5 (Effort)0.32 Months

 Development time does not increase linearly with product size:

 For larger products more parallel activities can be identified
 And can be carried out simultaneously by a number of engineers.
 Development time is roughly the same for all the three categories of products:
 For example, a 60 KLOC program can be developed in approximately 18 months
regardless of whether it is of organic, semi-detached, or embedded type.
 There is more scope for parallel activities for system and application programs, than
utility programs.

Example

The size of an organic software product has been estimated to be 32,000 lines of source code.
Determine the effort and nominal development time required.

Solution:
 Effort = 2.4*(32)1.05 = 91 PM
 Nominal development time = 2.5*(91)0.38 = 14 months

31
Intermediate COCOMO
 Basic COCOMO model assumes
 effort and development time depend on product size alone.
 However, several parameters affect effort and development time:
 Reliability requirements
 Availability of CASE tools and modern facilities to the developers
 Size of data to be handled
 For accurate estimation,
 the effect of all relevant parameters must be considered:
 Intermediate COCOMO model recognizes this fact:
 refines the initial estimate obtained by the basic COCOMO by using a set of 15 cost
drivers (multipliers).
 If modern programming practices are used,
 initial estimates are scaled downwards.
 If there are stringent reliability requirements on the product :
 initial estimate is scaled upwards.

 Rate different parameters on a scale of one to three:

 Depending on these ratings, multiply cost driver values with the estimate obtained using
the basic COCOMO.
 Cost driver classes:
 Product: Inherent complexity of the product, reliability requirements of the product, etc.
 Computer: Execution time, storage requirements, etc.
 Personnel: Experience of personnel, etc.
 Development Environment: Sophistication of the tools used for software development.

Shortcoming of basic and intermediate COCOMO models

Both models:
 consider a software product as a single homogeneous entity:
 However, most large systems are made up of several smaller sub-systems.
 Some sub-systems may be considered as organic type, some may be considered embedded,
etc.
 for some the reliability requirements may be high, and so on.

Complete COCOMO
 Cost of each sub-system is estimated separately.
 Costs of the sub-systems are added to obtain total cost.
 Reduces the margin of error in the final estimate.

Complete COCOMO Example

A Management Information System (MIS) for an organization having offices at several places across the
country:
 Database part (semi-detached)

32
 Graphical User Interface (GUI) part (organic)
 Communication part (embedded)
 Costs of the components are estimated separately
 Summed up to give the overall cost of the system.

Typical Problems with IT Cost Estimates

 Developing an estimate for a large software project is a complex task that requires a significant
amount of effort.
 People who develop estimates often do not have much experience.
 Human beings are biased toward underestimation.
 Management might ask for an estimate, but really desire a bid to win a major contract or get
internal funding.

Sample Cost Estimate

 Before creating an estimate, know what it will be used for, gather as much information about the
project as possible, and clarify the ground rules and assumptions for the estimate.
 If possible, estimate costs by major WBS categories.
 Create a cost model to make it easy to change and document the estimate.

# Units/Hrs Cost/Unit/Hr Subtotals WBS level 1 % of Total

Total
WBS Item
1. Project management $ 306,300 20%
1.1 Project manager 960 $100 $96,000
1.2 Project team members 1920 $75 $144,00
1.3 Contractors(10% of $66,300
software development
and testing)
2. Hardware $75,000 5%
2.1 Handheld devices 100 $600 $60,000
2.2 Servers 4 $4,000 $16,000
3. Software $614,000 40%
3.1 Licensed software 100 $200 $20,000
3.2 Software development $594,000
4. Testing(10% of total $69,000 $69,000 5%
hardware and software
costs)
5. Training and support $202,400 13%
5.1Trainee cost 100 $500 $50,000
5.2 Travel cost 12 $700 $8,400
5.3 Project Team members 1920 $75 $144,000

33
6. Reserves(20% of total $253,540 $253,540 17%
estimates)
Total project cost estimate $1,521,240

Cost Budgeting
 Cost budgeting involves allocating the project cost estimate to individual work items over time.
 The WBS is a required input for the cost budgeting process because it defines the work items.
 Important goal is to produce a cost baseline:
 A time-phased budget that project managers use to measure and monitor cost
performance.

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.

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.
• You must enter actual information periodically to use EVM.
• More and more organizations around the world are using EVM to help control project costs.

Earned Value Management Terms

 The planned value (PV), also called the budget, is that portion of the approved total cost estimate
planned to be spent on an activity during a given period.
 Actual cost (AC) is the total of direct and indirect costs incurred in accomplishing work on an
activity during a given period.
 The earned value (EV) 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.

Rate of Performance
 Rate of performance (RP) is the ratio of actual work completed to the amount of work planned
to have been completed at any given time during the life of the project or activity.
 For example, suppose the server installation was halfway completed by the end of week 1. The
rate of performance would be 50 percent because by the end of week 1, the planned schedule
reflects that the task should be 100 percent complete and only 50 percent of that work has been
completed.

34
 Budget At Completion (BAC) is the original total budget for the project.

Earned Value Formulas

Term Formula
Earned Value (EV) EV = PV to date X RP
Cost Variance (CV) CV = EV - AC
Schedule Variance (SV) SV = EV - PV
Cost Performance Index (CPI) CPI = EV/AC
Schedule Performance Index (SPI) SPI = EV/PV
Estimate at Completion (EAC) EAC = BAC/CPI
Estimate Time to Complete Original Time Estimate)/SPI

PV= Planned Value RP=Rate of Performance

AC= Actual Cost BAC = Budget at Completion

Rules of Thumb for Earned Value Numbers

 Negative numbers for cost and schedule variance indicate problems in those areas.
 A CPI or SPI that is less than 100 percent indicates problems.
 Problems mean the project is costing more than planned (over budget) or taking longer than
planned (behind schedule).

Project Portfolio Management

 Many organizations collect and control an entire suite of projects or investments as one set of
interrelated activities in a portfolio.
 Project portfolio management has five levels:
1. Put all your projects in one database.
2. Prioritize the projects in your database.
3. Divide your projects into two or three budgets based on type of investment.
4. Automate the repository.
5. Apply modern portfolio theory, including risk-return tools that map project risk on a
curve.

Benefits of Portfolio Management

35
 Organizations that evaluate information technology projects by what their business impacts are
and what their potential business values will be implement projects that result in 25 percent more
improvement to the bottom line.
 Portfolio management tools and techniques for IT projects enhance asset management, and
budget planning and monitoring.
 Using project portfolio management allows managers to make decisions faster and with more
confidence.

Using Software to Assist in Cost Management

 Spreadsheets are a common tool for resource planning, cost estimating, cost budgeting, and cost
control.
 Many companies use more sophisticated and centralized financial applications software for cost
information.
 Project management software has many cost-related features, especially enterprise PM software.

Project Quality Management

What Is Quality?
 The International Organization for Standardization (ISO) defines quality as “the degree to which
a set of inherent characteristics fulfils requirements” (ISO9000:2000).
 Other experts define quality based on:
 Conformance to requirements: The project’s processes and products meet written
specifications.
 Fitness for use: A product can be used as it was intended.

What Is Project Quality Management?

 Project quality management ensures that the project will satisfy the needs for which it was
undertaken.
 Processes include:
 Quality planning: Identifying which quality standards are relevant to the project and
how to satisfy them.
 Quality assurance: Periodically evaluating overall project performance to ensure the
project will satisfy the relevant quality standards.
 Quality control: Monitoring specific project results to ensure that they comply with the
relevant quality standards.

Quality Planning
 Implies the ability to anticipate situations and prepare actions to bring about the desired outcome.

36
 Important to prevent defects by:
 Selecting proper materials.
 Training and indoctrinating people in quality.
 Planning a process that ensures the appropriate outcome.

Design of Experiments
 Design of experiments is a quality planning technique that helps identify which variables have
the most influence on the overall outcome of a process.
 Also applies to project management issues, such as cost and schedule tradeoffs.
 Involves documenting important factors that directly contribute to meeting customer
requirements.

Scope Aspects of IT Projects

 Functionality is the degree to which a system performs its intended function.
 Features are the system’s special characteristics that appeal to users.
 System outputs are the screens and reports the system generates.
 Performance addresses how well a product or service performs the customer’s intended use.
 Reliability is the ability of a product or service to perform as expected under normal conditions.
 Maintainability addresses the ease of performing maintenance on a product.

Who’s Responsible for the Quality of Projects?

 Project managers are ultimately responsible for quality management on their projects.
 Several organizations and references can help project managers and their teams understand
quality.
 International Organization for Standardization (www.iso.org)
 IEEE (www.ieee.org)

Quality Assurance
 Quality assurance includes all the activities related to satisfying the relevant quality standards for
a project.
 Another goal of quality assurance is continuous quality improvement.
 Benchmarking generates ideas for quality improvements by comparing specific project practices
or product characteristics to those of other projects or products within or outside the performing
organization.
 A quality audit is a structured review of specific quality management activities that help identify
lessons learned that could improve performance on current or future projects.

Table of Contents for a Quality Assurance Plan

1.0 Draft Quality Assurance Plan
1.1 Introduction
1.2 Purpose
1.3 Policy Statement

37
1.4 Scope
2.0 Management
2.1 Organizational Structure
2.2 Roles and Responsibilities
2.2.1 Technical Monitor/Senior Management
2.2.2 Task Leader
2.2.3 Quality Assurance Team
2.2.4 Technical Staff
3.0 Required Documentation
4.0 Quality Assurance Procedures
4.1 Walkthrough Procedure
4.2 Review Process
4.2.1 Review Procedures
4.3 Audit Process
4.3.1 Audit Procedures
4.4 Evaluation Process
4.5 Process Improvement
5.0 Problem Reporting Procedures
5.1 Noncompliance Reporting Procedures
6.0 Quality Assurance Metrics
Appendix
Quality Assurance Checklist Forms
Quality Control
The main outputs of quality control are:
 Acceptance decisions
 Rework
 Process adjustments

Some tools and techniques include:

 Pareto analysis
 Statistical sampling
 Six Sigma
 Quality control charts

Pareto Analysis
 Pareto analysis involves identifying the vital few contributors that account for the most quality
problems in a system.
 Also called the 80-20 rule, meaning that 80 percent of problems are often due to 20 percent of the
causes.
 Pareto diagrams are histograms, or column charts representing a frequency distribution, that
help identify and prioritize problem areas.

Statistical Sampling
• Statistical sampling involves choosing part of a population of interest for inspection.

38
• The size of a sample depends on how representative you want the sample to be.
• Be sure to consult with an expert when using statistical analysis.

The Sample Size Formula

 The size of the sample depends on how representative you want it to be
 Sample size = 0.25 X (certainty factor/acceptable error)2
 Example: If you would accept a 95% certainty that a sample would contain no variation unless it
was present in the total population
 Sample size = 0.25 X (1.960/0.05)2 = 384
 For 90% certainty
 Sample size = 0.25 X (1.645/0.10)2 = 68
 Hence for 90% certainty would need to examine 68 items.

Desired Certainty Certainty factor

95% 1.960
90% 1.645
80% 1.281

Six Sigma
• Six Sigma is “a comprehensive and flexible system for achieving, sustaining, and maximizing business
success. Six Sigma is uniquely driven by close understanding of customer needs, disciplined use of facts,
data, and statistical analysis, and diligent attention to managing, improving, and reinventing business
processes.”

Basic Information on Six Sigma

 The target for perfection is the achievement of no more than 3.4 defects per million
opportunities.
 The principles can apply to a wide variety of processes.
 Six Sigma projects normally follow a five phase improvement process called DMAIC.

DMAIC
• DMAIC is a systematic, closed-loop process for continued improvement that is scientific and fact
based.

DMAIC stands for:

 Define: Define the problem/opportunity, process, and customer requirements.
 Measure: Define measures, then collect, compile, and display data.
 Analyze: Scrutinize process details to find improvement opportunities.
 Improve: Generate solutions and ideas for improving the problem.
 Control: Track and verify the stability of the improvements and the predictability of the solution.

39
How is Six Sigma Quality Control Unique?
 It requires an organization-wide commitment.
 Training follows the “Belt” system.
 Six Sigma organizations have the ability and willingness to adopt contrary objectives, such as
reducing errors and getting things done faster.
 It is an operating philosophy that is customer focused and strives to drive out waste, raise levels
of quality, and improve financial performance at breakthrough levels.

Six Sigma and Project Management

 All improvement takes place project by project, and in no other way.
 It’s important to select projects carefully and apply higher quality where it makes sense
 Six Sigma projects must focus on a quality problem or gap between the current and desired
performance and not have a clearly understood problem or a predetermined solution.

Six Sigma Projects Use Project Management

 The training for Six Sigma includes many project management concepts, tools, and techniques.
 For example, Six Sigma projects often use business cases, project charters, schedules, budgets,
and so on.
 Six Sigma projects are done in teams; the project manager is often called the team leader, and the
sponsor is called the champion.

Six Sigma and Statistics

 The term sigma means standard deviation.
 Standard deviation measures how much variation exists in a distribution of data.

Six Sigma Uses a Conversion Table

 Using a normal curve, if a process is at six sigma, there would be no more than two defective
units per billion produced.
 Six Sigma uses a scoring system that accounts for time, an important factor in determining
process variations.
 Yield represents the number of units handled correctly through the process steps.
 A defect is any instance where the product or service fails to meet customer requirements.
 There can be several opportunities to have a defect.

Six 9s of Quality
 Six 9s of quality is a measure of quality control equal to 1 fault in 1 million opportunities.
 In the telecommunications industry, it means 99.9999 percent service availability or 30 seconds
of down time a year.
 This level of quality has also been stated as the target goal for the number of errors in a
communications circuit, system failures, or errors in lines of code.

Quality Control Charts

40
 A control chart is a graphic display of data that illustrates the results of a process over time.
 The main use of control charts is to prevent defects, rather than to detect or reject them.
 Quality control charts allow you to determine whether a process is in control or out of control.
 When a process is in control, any variations in the results of the process are created by
random events; processes that are in control do not need to be adjusted.
 When a process is out of control, variations in the results of the process are caused by
non-random events; you need to identify the causes of those nonrandom events and adjust
the process to correct or eliminate them.

The Seven Run Rule

 You can use quality control charts and the seven run rule to look for patterns in data.
 The seven run rule states that if seven data points in a row are all below the mean, above the
mean, or are all increasing or decreasing, then the process needs to be examined for non-random
problems.

Testing
 Many IT professionals think of testing as a stage that comes near the end of IT product
development.
 Testing should be done during almost every phase of the IT product development life cycle.

Types of Tests
 Unit testing tests each individual component (often a program) to ensure it is as defect-free as
possible.
 Integration testing occurs between unit and system testing to test functionally grouped
components.
 System testing tests the entire system as one entity.
 User acceptance testing is an independent test performed by end users prior to accepting the
delivered system.

Testing Alone Is Not Enough

 Watts S. Humphrey, a renowned expert on software quality, defines a software defect as
anything that must be changed before delivery of the program.
 Testing does not sufficiently prevent software defects because:
 The number of ways to test a complex system is huge.
 Users will continue to invent new ways to use a system that its developers never
considered.
 Humphrey suggests that people rethink the software development process to provide no potential
defects when you enter system testing; developers must be responsible for providing error-free
code at each stage of testing.

Modern Quality Management

 Modern quality management:

41
 Requires customer satisfaction.
 Prefers prevention to inspection.
 Recognizes management responsibility for quality.

ISO Standards
 ISO 9000 is a quality system standard that:
 Is a three-part, continuous cycle of planning, controlling, and documenting quality in an
organization.
 Provides minimum requirements needed for an organization to meet its quality
certification standards.
 Helps organizations around the world reduce costs and improve customer satisfaction.
 ISO 15504, sometimes known as SPICE (Software Process Improvement and Capability
dEtermination), is a framework for the assessment of software processes.

Improving Information Technology Project Quality

Several suggestions for improving quality for IT projects include:
 Establish leadership that promotes quality.
 Understand the cost of quality.
 Focus on organizational influences and workplace factors that affect quality.
 Follow maturity models.

Leadership
 It is most important that top management be quality-minded. In the absence of sincere
manifestation of interest at the top, little will happen below.
 A large percentage of quality problems are associated with management, not technical issues.

The Cost of Quality

The cost of quality is the cost of conformance plus the cost of nonconformance.
 Conformance means delivering products that meet requirements and fitness for use.
 Cost of nonconformance means taking responsibility for failures or not meeting quality
expectations.

A 2002 study reported that software bugs cost the U.S. economy $59.6 billion each year and that one third
of the bugs could be eliminated by an improved testing infrastructure.

Five Cost Categories Related to Quality

 Prevention cost: Cost of planning and executing a project so it is error-free or within an
acceptable error range.
 Appraisal cost: Cost of evaluating processes and their outputs to ensure quality.
 Internal failure cost: Cost incurred to correct an identified defect before the customer receives
the product.
 External failure cost: Cost that relates to all errors not detected and corrected before delivery to
the customer.

42
 Measurement and test equipment costs: Capital cost of equipment used to perform prevention
and appraisal activities.

Expectations and Cultural Differences in Quality

 Project managers must understand and manage stakeholder expectations.
 Expectations also vary by:
 Organization’s culture
 Geographic regions

Maturity Models
 Maturity models are frameworks for helping organizations improve their processes and systems.
 The Software Quality Function Deployment Model focuses on defining user
requirements and planning software projects.
 The Software Engineering Institute’s Capability Maturity Model is a five-level model
laying out a generic path to process improvement for software development in
organizations.

CMM Levels and CMMI

 CMM levels, from lowest to highest, are:
1. Initial
2. Repeatable
3. Defined
4. Managed
5. Optimizing
 The Capability Maturity Model Integration (CMMI) is replacing the older CMM ratings and
addresses software engineering, system engineering, and program management.
 Companies may not get to bid on government projects unless they have a CMMI Level 3.

PMI’s Maturity Model

 PMI released the Organizational Project Management Maturity Model (OPM3) in December
2003.
 Model is based on market research surveys sent to more than 30,000 project management
professionals and incorporates 180 best practices and more than 2,400 capabilities, outcomes, and
key performance indicators.
 Addresses standards for excellence in project, program, and portfolio management best practices
and explains the capabilities necessary to achieve those best practices.

Using Software to Assist in Project Quality Management

 Spreadsheet and charting software helps create Pareto diagrams, fishbone diagrams, and so on.
 Statistical software packages help perform statistical analysis.
 Specialized software products help manage Six Sigma projects or create quality control charts.
 Project management software helps create Gantt charts and other tools to help plan and track
work related to quality management.

43
Project Human Resource Management
The Importance of Human Resource Management
 People determine the success and failure of organizations and projects.
 Many people are struggling with how to increase and diversify the IT labor pool.
 Noted problems include:
 The fact that many IT professionals work long hours and must constantly stay abreast of
changes in the field.
 Undesirable stereotypes that keep certain people (for example, women) away from the
career field.
 The need to improve benefits, redefine work hours and incentives, and provide better
human resource management.

What is Project Human Resource Management?

 Making the most effective use of the people involved with a project.
 Processes include:
 Human resource planning: Identifying and documenting project roles, responsibilities,
and reporting relationships.
 Acquiring the project team: Getting the needed personnel assigned to and working on
the project.
 Developing the project team: Building individual and group skills to enhance project
performance.
 Managing the project team: Tracking team member performance, motivating team
members, providing timely feedback, resolving issues and conflicts, and coordinating
changes to help enhance project performance.

Keys to Managing People

 Psychologists and management theorists have devoted much research and thought to the field of
managing people at work.
 Important areas related to project management include:
 Motivation theories
 Influence and power
 Effectiveness

Intrinsic and Extrinsic Motivation

 Intrinsic motivation causes people to participate in an activity for their own enjoyment.
 Extrinsic motivation causes people to do something for a reward or to avoid a penalty.
 For example, some children take piano lessons for intrinsic motivation (they enjoy it) while
others take them for extrinsic motivation (to get a reward or avoid punishment).

Maslow’s Hierarchy of Needs

 Abraham Maslow argued that human beings possess unique qualities that enable them to make
independent choices, thus giving them control of their destiny.

44
 Maslow developed a hierarchy of needs, which states that people’s behaviors are guided or
motivated by a sequence of needs.

High

5. Self
actualization

4. Esteem

3. Social

2. Safety

1. Physiological
Low
A satisfied need is no longer a motivator!
Herzberg’s Motivational and Hygiene Factors
 Frederick Herzberg wrote several famous books and articles about worker motivation. He
distinguished between:
 Motivational factors: Achievement, recognition, the work itself, responsibility,
advancement, and growth. These factors produce job satisfaction.
 Hygiene factors: Larger salaries, more supervision, and a more attractive work
environment. These factors cause dissatisfaction if not present, but do not motivate
workers to do more

McClelland’s Acquired-Needs Theory

 Specific needs are acquired or learned over time and are shaped by life experiences. The
following are the main categories of acquired needs:
 Achievement (nAch): People with a high need for achievement like challenging projects
with attainable goals and lots of feedback.
 Affiliation (nAff): People with high need for affiliation desire harmonious relationships
and need to feel accepted by others, so managers should try to create a cooperative work
environment for them.
 Power (nPow): People with a need for power desire either personal power (not good) or
institutional power (good for the organization). Provide institutional power seekers with
management opportunities.

McGregor’s Theory X and Y

 Douglas McGregor popularized the human relations approach to management in the 1960s.

45
 Theory X: Assumes workers dislike and avoid work, so managers must use coercion, threats, and
various control schemes to get workers to meet objectives.
 Theory Y: Assumes individuals consider work as natural as play or rest and enjoy the satisfaction
of esteem and self-actualization needs.
 Theory Z: Introduced in 1981 by William Ouchi and is based on the Japanese approach to
motivating workers, which emphasizes trust, quality, collective decision making, and cultural
values.

Thamhain and Wilemon’s Ways to Have Influence on Projects

1. Authority: The legitimate hierarchical right to issue orders.
2. Assignment: The project manager's perceived ability to influence a worker's later work
assignments.
3. Budget: The project manager's perceived ability to authorize others' use of discretionary funds.
4. Promotion: The ability to improve a worker's position.
5. Money: The ability to increase a worker's pay and benefits.
6. Penalty: The project manager's ability to cause punishment.
7. Work challenge: The ability to assign work that capitalizes on a worker's enjoyment of doing a
particular task.
8. Expertise: The project manager's perceived special knowledge that others deem important.
9. Friendship: The ability to establish friendly personal relationships between the project manager
and others.

Ways to Influence that Help and Hurt Projects

• Projects are more likely to succeed when project managers influence people using:
– Expertise
–Work challenge
• Projects are more likely to fail when project managers rely too heavily on:
– Authority
– Money
– Penalty

Power
 Power is the potential ability to influence behavior to get people to do things they would not
otherwise do.
 Types of power include:
 Coercive power
 Legitimate power
 Expert power
 Reward power
 Referent power

Improving Effectiveness: Covey’s Seven Habits

 Project managers can apply Covey’s seven habits to improve effectiveness on projects.

46
 Be proactive.
 Begin with the end in mind.
 Put first things first.
 Think win/win.
 Seek first to understand, then to be understood.
 Synergize.
 Sharpen the saw.

Empathic Listening and Rapport

 Good project managers are empathic listeners, meaning they listen with the intent to understand.
 Before you can communicate with others, you have to have rapport, which is a relation of
harmony, conformity, accord, or affinity.
 Mirroring is the matching of certain behaviors of the other person, and is a technique used to
help establish rapport.
 IT professionals need to develop empathic listening and other people skills to improve
relationships with users and other stakeholders.
Organizational Planning
 Involves identifying and documenting project roles, responsibilities, and reporting relationships.
 Outputs include:
 Project organizational charts
 Staffing management plans
 Responsibility assignment matrixes
 Resource histograms

Sample Organizational Chart for a Large IT Project

47
Project manager

Deputy Project manager

Systems Independent Project Quality Configuration

Engineering Test Group Technical Lead Assurance management

SW Subproject SW Subproject SW Subproject

Manager 1 Manager 2 Manager 3

Team 1 Team 2 Team 1 Team 2 Team 1 Team 2

Responsibility Assignment Matrixes

 A responsibility assignment matrix (RAM) is a matrix that maps the work of the project, as
described in the WBS, to the people responsible for performing the work, as described in the
OBS.
 Can be created in different ways to meet unique project needs.

Staffing Management Plans and Resource Histograms

 A staffing management plan describes when and how people will be added to and taken off the
project team.
 A resource histogram is a column chart that shows the number of resources assigned to a project
over time.

Acquiring the Project Team

 Acquiring qualified people for teams is crucial.
 The project manager who is the smartest person on the team has done a poor job of recruiting!
 Staffing plans and good hiring procedures are important, as are incentives for recruiting and
retention.
 Some companies give their employees one dollar for every hour that a new person who
they helped hire works.
 Some organizations allow people to work from home as an incentive.
Why People Leave Their Jobs
 They feel they do not make a difference.

48
 They do not get proper recognition.
 They are not learning anything new or growing as a person.
 They do not like their coworkers.
 They want to earn more money.

Resource Loading
 Resource loading refers to the amount of individual resources an existing schedule requires
during specific time periods.
 Helps project managers develop a general understanding of the demands a project will make on
the organization’s resources and individual people’s schedules.
 Over allocation means more resources than are available are assigned to perform work at a given
time.

Resource Leveling
 Resource leveling is a technique for resolving resource conflicts by delaying tasks.
 The main purpose of resource leveling is to create a smoother distribution of resource use and
reduce over allocation.

Benefits of Resource Leveling

 When resources are used on a more constant basis, they require less management.
 It may enable project managers to use a just-intime inventory type of policy for using
subcontractors or other expensive resources.
 It results in fewer problems for project personnel and the accounting department.
 It often improves morale.

Developing the Project Team

 The main goal of team development is to help people work together more effectively to improve
project performance.
 It takes teamwork to successfully complete most projects.

Tuckman Model of Team Development

 Forming
 Storming
 Norming
 Performing
 Adjourning

Training
 Training can help people understand themselves and each other, and understand how to work
better in teams.
 Team building activities include:
 Physical challenges
 Psychological preference indicator tools

49
Myers-Briggs Type Indicator (MBTI)
 MBTI is a popular tool for determining personality preferences and helping teammates
understand each other.
 Four dimensions include:
 Extrovert/Introvert (E/I)
 Sensation/Intuition (S/N)
 Thinking/Feeling (T/F)
 Judgment/Perception (J/P)
 NTs, or rationals, are attracted to technology fields.
 IT people vary most from the general population in their tendency to not be extroverted or
sensing.

Wideman and Shenhar’s Views on MBTI and Project Management

 Most suited for project leadership:
 100 percent: INTJ, ENTJ, ISTJ, ESTJ
 50 percent: INTP, ENTP, ENFP, ENFJ
 Best suited as followers:
 100 percent: INFJ, ISFJ
 50 percent: INTP, ENTP, ENFP, ENFJ, ESFJ
 Not suited for project work:
 100 percent: INFP, ISFP, ESFP, ISTP
 50 percent: ENFP, ESTP

Social Styles Profile

 People are perceived as behaving primarily in one of four zones, based on their assertiveness and
responsiveness:
 Drivers
 Expressives
 Analyticals
 Amiables
 People on opposite corners (drivers and amiables, analyticals and expressives) may have
difficulty getting along.

Reward and Recognition Systems

 Team-based reward and recognition systems can promote teamwork.
 Focus on rewarding teams for achieving specific goals.
 Allow time for team members to mentor and help each other to meet project goals and develop
human resources.

Managing the Project Team

50
 Project managers must lead their teams in performing various project activities.
 After assessing team performance and related information, the project manager must decide:
 If changes should be requested to the project.
 If corrective or preventive actions should be recommended.
 If updates are needed to the project management plan or organizational process assets.

Tools and Techniques for Managing Project Teams

 Observation and conversation
 Project performance appraisals
 Conflict management
 Issue logs

General Advice on Teams

 Be patient and kind with your team.
 Fix the problem instead of blaming people.
 Establish regular, effective meetings.
 Allow time for teams to go through the basic team-building stages.
 Limit the size of work teams to three to seven members.
 Plan some social activities to help project team members and other stakeholders get to know each
other better.
 Stress team identity.
 Nurture team members and encourage them to help each other.
 Take additional actions to work with virtual team members.

Using Software to Assist in Human Resource Management

 Software can help produce RAMS and resource histograms.
 By using project management software for human resource management, you can:
 Assign resources.
 Identify potential resource shortages or underutilization.
 Level resources.

Project Resource Management Involves Much More Than Using Software

 Project managers must:
 Treat people with consideration and respect.
 Understand what motivates people.
 Communicate carefully with people.
 Focus on your goal of enabling project team members to deliver their best work.

Software project risk management

51
 Project risk is an event or a problem that might impede project success if allowed to occur.
 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 involves anticipating risks that might affect the project schedule or the
quality of the software being developed and taking action to avoid these risks.
 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.

Stages involve in software risk management process

Software risk management process involves four stages

 Risk identification
 Risk analysis
 Risk planning
 Risk monitoring

Risk identification

 The possible project, product and business risks are identified.

 It is concerned with discovering possible risks likely to affect a project and documenting the
characteristics of each.

Risk identification tools and techniques include:

 Brainstorming
 The Delphi Technique
 Interviewing
 SWOT analysis

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.

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.

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

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

Risk Register
 The main output of the risk identification process is a list of identified risks and other information
needed to begin creating a risk register.
 A risk register is:
 A document that contains the results of various risk management processes and that is
often displayed in a table or spreadsheet format.
 A tool for documenting potential risk events and related information.
 Risk events refer to specific, uncertain events that may occur to the detriment or of the project.

Risk Register Contents

 An identification number for each risk event.
 A rank for each risk event.
 The name of each risk event.
 A description of each risk event.
 The category under which each risk event falls.
 The root cause of each risk.
 Triggers for each risk; triggers are indicators or symptoms of actual risk events.
 Potential responses to each risk.
 The risk owner or person who will own or take responsibility for each risk.
 The probability and impact of each risk occurring.
 The status of each risk.

Risk analysis

 The likelihood and consequences of the identified risks are assessed

 Qualitative risk analysis: Prioritizing risks based on their probability and impact of occurrence.
 Quantitative risk analysis: Numerically estimating the effects of risks on project objectives.

Risk planning

 Deciding how to approach and plan the risk management activities for the project.
 The plan to address the risk either by avoiding or minimizing its effects on the project are
drawn up.
53
 The main output of risk management planning is a risk management plan - a plan that
documents the procedures for managing risk throughout a project.
 The project team should review project documents and understand the organization’s and the
sponsor’s approaches to risk.

Contingency and Fallback Plans, Contingency Reserves

 Contingency plans are predefined actions that the project team will take if an identified risk
event occurs.
 Fallback plans are developed for risks that have a high impact on meeting project objectives, and
are put into effect if attempts to reduce the risk are not effective.
 Contingency reserves or allowances are provisions held by the project sponsor or organization
to reduce the risk of cost or schedule overruns to an acceptable level.

Risk Breakdown Structure

 A risk breakdown structure is a hierarchy of potential risk categories for a project.
 Similar to a work breakdown structure but used to identify and categorize risks.

54
Sample Risk Breakdown Structure
IT Project

Business Technical Organizational Project Management

Competitors Executive Estimate

Hardware

Communication
Suppliers Software User support

Work flow Network Team support Resources

Risk monitoring

 The risk is constantly assessed and plans to mitigate risk are revised as more information
about the risk becomes available.
 It involves executing the risk management process to respond to risk events.
 Main outputs of risk monitoring and control are:
 Requested changes.
 Recommended corrective and preventive actions.
 Updates to the risk register, project management plan, and organizational process assets.

Risk Response Planning

 After identifying and quantifying risks, you must decide how to respond to them.
 There are three types of strategies that can be used to establish risk management plans

1. Avoidance strategies: If these strategies are used then it means that the probability that
the risk will occur is reduced
2. Minimization strategies: Following these strategies means that the impact of the risk
will be reduced
3. Contingency plans: following these strategies means that you are prepare for the worse
and have a strategy in plan to deal with the risk

55
Project Communications Management

Importance of Good Communications

 The greatest threat to many projects is a failure to communicate.
 Our culture does not portray IT professionals as being good communicators.
 Research shows that IT professionals must be able to communicate effectively to succeed in their
positions.
 Strong verbal skills are a key factor in career advancement for IT professionals.

Project Communications Management Processes

 Communications planning: Determining the information and communications needs of the
stakeholders.
 Information distribution: Making needed information available to project stakeholders in a
timely manner.
 Performance reporting: Collecting and disseminating performance information, including status
reports, progress measurement, and forecasting.
 Managing stakeholders: Managing communications to satisfy the needs and expectations of
project stakeholders and to resolve issues.

Communications Planning
 Every project should include some type of communications management plan, a document that
guides project communications.
 Creating a stakeholder analysis for project communications also aids in communications
planning.

Communications Management Plan Contents

 Stakeholder communications requirements.
 Information to be communicated, including format, content, and level of detail.
 The people who will receive the information and who will produce it.
 Suggested methods or technologies for conveying the information.
 Frequency of communication.
 Escalation procedures for resolving issues.
 Revision procedures for updating the communications management plan.
 A glossary of common terminology.

Information Distribution
 Getting the right information to the right people at the right time and in a useful format is just as
important as developing the information in the first place.
 Important considerations include:
 Using technology to enhance information distribution.
 Formal and informal methods for distributing information.

56
Distributing Information in an Effective and Timely Manner
 Don’t bury crucial information.
 Don’t be afraid to report bad information.
 Oral communication via meetings and informal talks helps bring important information—good
and bad—out into the open.

Importance of Face-to-Face Communication

Research says that in a face-to-face interaction:
 58 percent of communication is through body language.
 35 percent of communication is through how the words are said.
 7 percent of communication is through the content or words that are spoken.
 Pay attention to more than just the actual words someone is saying.
 A person’s tone of voice and body language say a lot about how he or she really feels.

Encouraging More Face-to- Face Interactions

 Short, frequent meetings are often very effective in IT projects.
 Stand-up meetings force people to focus on what they really need to communicate.
 Some companies have policies preventing the use of e-mail between certain hours or even entire
days of the week.

Media Snapshot
 Live video is a modern medium for sending information.
 Microsoft says that one in every five face-to-face meetings can be replaced with Web
conferencing tools, and they estimate it will save $70 million in reduced travel in one year alone.*

Understanding Group and Individual Communication Needs

 People are not interchangeable parts.
 As illustrated in Brooks’ book The Mythical Man-Month, you cannot assume that a task originally
scheduled to take two months of one person’s time can be done in one month by two people.

Personal Preferences Affect Communication Needs

 Introverts like more private communications, while extroverts like to discuss things in public.
 Intuitive people like to understand the big picture, while sensing people need step-by-step details.
 Thinkers want to know the logic behind decisions, while feeling people want to know how
something affects them personally.
 Judging people are driven to meet deadlines while perceiving people need more help in
developing and following plans.

Other Communication Considerations

 Rarely does the receiver interpret a message exactly as the sender intended.
 Geographic location and cultural background affect the complexity of project communications.
 Different working hours
 Language barriers

57
 Different cultural norms

Determining the Number of Communications Channels

 As the number of people involved increases, the complexity of communications increases
because there are more communications channels or pathways through which people can
communicate.
 Number of communications channels = n(n-1)/2 where n is the number of people involved.

Performance Reporting
 Performance reporting keeps stakeholders informed about how resources are being used to
achieve project objectives.
 Status reports describe where the project stands at a specific point in time.
 Progress reports describe what the project team has accomplished during a certain period of
time.
 Forecasts predict future project status and progress based on past information and trends.

Managing Stakeholders
 Project managers must understand and work with various stakeholders.
 Need to devise a way to identify and resolve issues.
 Two important tools include:
 Expectations management matrix
 Issue log

Suggestions for Improving Project Communications

 Manage conflicts effectively.
 Develop better communication skills.
 Run effective meetings.
 Use e-mail effectively.
 Use templates for project communications.

Conflict Handling Modes

1. Confrontation: Directly face a conflict using a problem-solving approach.
2. Compromise: Use a give-and-take approach.
3. Smoothing: De-emphasize areas of difference and emphasize areas of agreement.
4. Forcing: The win-lose approach.
5. Withdrawal: Retreat or withdraw from an actual or potential disagreement.

Conflict Can Be Good

 Conflict often produces important results, such as new ideas, better alternatives, and motivation to
work harder and more collaboratively.
 Groupthink: Conformance to the values or ethical standards of a group. Groupthink can develop
if there are no conflicting viewpoints.

58
 Research suggests that task-related conflict often improves team performance, but emotional
conflict often depresses team performance.

Developing Better Communication Skills

 Companies and formal degree programs for IT professionals often neglect the importance of
speaking, writing, and listening skills.
 As organizations become more global, they realize they must invest in ways to improve
communication with people from different countries and cultures.
 It takes leadership to improve communication.

Running Effective Meetings

 Determine if a meeting can be avoided.
 Define the purpose and intended outcome of the meeting.
 Determine who should attend the meeting.
 Provide an agenda to participants before the meeting.
 Prepare handouts and visual aids, and make logistical arrangements ahead of time.
 Run the meeting professionally.
 Build relationships.

Using E-Mail Effectively

 Make sure that e-mail is an appropriate medium for what you want to communicate.
 Be sure to send the e-mail to the right people.
 Use meaningful subject lines.
 Limit the content to one main subject, and be as clear and concise as possible.
 Limit the number and size of attachments.
 Delete e-mail you don’t need, and don’t open e-mail if you question the source.
 Make sure your virus software is current.
 Respond to and file e-mails quickly.
 Learn how to use important features.

Using Templates for Project Communications

 Many technical people are afraid to ask for help.
 Providing examples and templates for project communications saves time and money.
 Organizations can develop their own templates, use some provided by outside organizations, or
use samples from textbooks.
 Recall that research shows that companies that excel in project management make effective use of
templates.

Developing a Communications Infrastructure

 A communications infrastructure is a set of tools, techniques, and principles that provide a
foundation for the effective transfer of information.
 Tools include e-mail, project management software, groupware, fax machines, telephones,
teleconferencing systems, document management systems, and word processors.

59
 Techniques include reporting guidelines and templates, meeting ground rules and procedures,
decision-making processes, problem-solving approaches, and conflict resolution and negotiation
techniques.
 Principles include using open dialog and an agreed upon work ethic.

Using Software to Assist in Project Communications

 There are many software tools to aid in project communications.
 Today more than 37 percent of people telecommute or work remotely at least part-time.
 Project management software includes new capabilities to enhance virtual communications.
 New tools, such as instant messaging and blogs, can enhance project communications.

Project Procurement Management

Importance of Project Procurement Management

 Procurement means acquiring goods and/or services from an outside source.
 Other terms include purchasing and outsourcing.
 Experts predict that global spending on computer software and services will continue to grow.
 India is the leading country for U.S. offshore outsourcing.

Debates on Outsourcing
 Some companies, such as Wal-Mart, prefer to do no outsourcing at all, while others do a lot of
outsourcing.
 Most organizations do some form of outsourcing to meet their IT needs and spend most money
within their own country.
 The U.S. temporary workforce continues to grow as people work for temporary job agencies so
they can more easily move from company to company.

Why Outsource?
 To reduce both fixed and recurrent costs.
 To allow the client organization to focus on its core business.
 To access skills and technologies.
 To provide flexibility.
 To increase accountability.

Contracts
 A contract is a mutually binding agreement that obligates the seller to provide the specified
products or services and obligates the buyer to pay for them.
 Contracts can clarify responsibilities and sharpen focus on key deliverables of a project.
 Because contracts are legally binding, there is more accountability for delivering the work as
stated in the contract.
 A recent trend in outsourcing is the increasing size of contracts.

60
Project Procurement Management Processes
Project procurement management: Is the acquiring goods and services for a project from outside the
performing organization.
The Project Procurement Management Processes include:
 Planning purchases and acquisitions: Determining what to procure, when, and how.
 Planning contracting: Describing requirements for the products or services desired from the
procurement and identifying potential sources or sellers (contractors, suppliers, or providers who
provide goods and services to other organizations).
 Requesting seller responses: Obtaining information, quotes, bids, offers, or proposals from
sellers, as appropriate.
 Selecting sellers: Choosing from among potential suppliers through a process of evaluating
potential sellers and negotiating the contract.
 Administering the contract: Managing the relationship with the selected seller.
 Closing the contract: Completing and settling each contract, including resolving any open items.

Planning Purchases and Acquisitions

 Identifying which project needs can best be met by using products or services outside the
organization.
 If there is no need to buy any products or services from outside the organization, then there is no
need to perform any of the other procurement management processes.

Tools and Techniques for Planning Purchases and Acquisitions

 Make-or-buy analysis: General management technique used to determine whether an
organization should make or perform a particular product or service inside the organization or
buy from someone else.
 Often involves financial analysis.
 Experts, both internal and external, can provide valuable inputs in procurement decisions.

Make-or-Buy Example
 Assume you can lease an item you need for a project for $800/day. To purchase the item, the cost
is $12,000 plus a daily operational cost of $400/day.
 How long will it take for the purchase cost to be the same as the lease cost?

Make-or Buy Solution

 Set up an equation so both options, purchase and lease, are equal.
 In this example, use the following equation. Let d be the number of days to use the item:
$12,000 + $400d = $800d
Subtracting $400d from both sides, you get:
$12,000 = $400d
Dividing both sides by $400, you get:
d = 30
 If you need the item for more than 30 days, it is more economical to purchase it.

61
Types of Contracts
 Different types of contracts can be used in different situations:
 Fixed price or lump sum contracts: Involve a fixed total price for a well-defined product
or service.
 Cost reimbursable contracts: Involve payment to the seller for direct and indirect costs.
 Time and material contracts: Hybrid of both fixed price and cost reimbursable contracts,
often used by consultants.
 Unit price contracts: Require the buyer to pay the seller a predetermined amount per unit
of service.
 A single contract can actually include all four of these categories, if it makes sense for that
particular procurement.

Cost Reimbursable Contracts

 Cost plus incentive fee (CPIF): The buyer pays the supplier for allowable performance costs
plus a predetermined fee and an incentive bonus.
 Cost plus fixed fee (CPFF): The buyer pays the supplier for allowable performance costs plus a
fixed fee payment usually based on a percentage of estimated costs.
 Cost plus percentage of costs (CPPC): The buyer pays the supplier for allowable performance
costs plus a predetermined percentage based on total costs.

Contract Types Versus Risk

Buyer risk
low
high

CPP CPFF CPIF FPI FFP

Cost plus Cost plus Cost plus Fixed price Firm fixed
percentage fixed free incentive incentive price
of costs free

Seller risk
high
low

Contract Clauses
 Contracts should include specific clauses to take into account issues unique to the project.
 Can require various educational or work experience for different pay rights.
 A termination clause is a contract clause that allows the buyer or supplier to end the contract.

Procurement Management Plan

 Describes how the procurement processes will be managed, from developing documentation for
making outside purchases or acquisitions to contract closure.
 Content varies based on project needs.

62
Contract Statement of Work (SOW)
 A statement of work is a description of the work required for the procurement.
 If a SOW is used as part of a contract to describe only the work required for that particular
contract, it is called a contract statement of work.
 A SOW is a type of scope statement.
 A good SOW gives bidders a better understanding of the buyer’s expectations.

Statement of Work (SOW) Template

I. Scope of Work: Describe the work to be done to detail. Specify the hardware and software
involved and the exact nature of the work.
II. Location of Work: Describe where the work must be performed. Specify the location of
hardware and software and where the people must perform the work
III. Period of Performance: Specify when the work is expected to start and end, working hours,
number of hours that can be billed per week, where the work must be performed, and related
schedule information.
IV. Deliverables Schedule: List specific deliverables, describe them in detail, and specify when they
are due.
V. Applicable Standards: Specify any company or industry-specific standards that are relevant to
performing the work.
VI. Acceptance Criteria: Describe how the buyer organization will determine if the work is
acceptable.
VII. Special Requirements: Specify any special requirements such as hardware or software
certifications, minimum degree or experience level of personnel, travel requirements, and so on.

Planning Contracting
 Involves preparing several documents needed for potential sellers to prepare their responses and
determining the evaluation criteria for the contract award.
 Request for Proposals: Used to solicit proposals from prospective sellers.
 A proposal is a document prepared by a seller when there are different approaches for meeting
buyer needs.
 Requests for Quotes: Used to solicit quotes or bids from prospective suppliers.
 A bid, also called a tender or quote (short for quotation), is a document prepared by sellers
providing pricing for standard items that have been clearly defined by the buyer.

Request for Proposal (RFP) Template

I. Purpose of RFP
II. Organization’s Background
III. Basic Requirements
IV. Hardware and Software Environment
V. Description of RFP Process
VI. Statement of Work and Schedule Information
VII. Possible Appendices

63
A. Current System Overview
B. System Requirements
C. Volume and Size Data
D. Required Contents of Vendor’s Response to RFP
E. Sample Contract

Evaluation Criteria
 It’s important to prepare some form of evaluation criteria, preferably before issuing a formal RFP
or RFQ.
 Beware of proposals that look good on paper; be sure to evaluate factors, such as past
performance and management approach.
 Can require a technical presentation as part of a proposal.

Requesting Seller Responses

 Deciding whom to ask to do the work, sending appropriate documentation to potential sellers, and
obtaining proposals or bids.
 Organizations can advertise to procure goods and services in several ways:
 Approaching the preferred vendor.
 Approaching several potential vendors.
 Advertising to anyone interested.
 A bidders’ conference can help clarify the buyer’s expectations.

Selecting Sellers
 Also called source selection.
 Involves:
 Evaluating proposals or bids from sellers.
 Choosing the best one.
 Negotiating the contract.
 Awarding the contract.

Sample Proposal Evaluation Sheet

Proposal 1 Proposal 2 Proposal 3
Criteria Weight Rating Score Rating Score Rating Score
Technical approach 30%
Management 30%
approach
Past performance 20%
Price 20%
Total score 100%

64
Seller Selection Process
 Organizations often do an initial evaluation of all proposals and bids and then develop a short list
of potential sellers for further evaluation.
 Sellers on the short list often prepare a best and final offer (BAFO).
 Final output is a contract signed by the buyer and the selected seller.

Media Snapshot
 Many organizations realize that selecting appropriate sellers can often provide a win-win
situation.
 Several companies, including those owned by famous celebrities, work closely with outside
sources to help both parties come out ahead.
 For example, Oprah Winfrey celebrated the premiere of her show’s nineteenth season by giving
each of her 276 audience members a new car that was donated by Pontiac.

Administering the Contract

 Ensures that the seller’s performance meets contractual requirements.
 Contracts are legal relationships, so it is important that legal and contracting professionals be
involved in writing and administering contracts.
 Many project managers ignore contractual issues, which can result in serious problems.

Suggestions for Change Control in Contracts

 Changes to any part of the project need to be reviewed, approved, and documented by the same
people in the same way that the original part of the plan was approved.
 Evaluation of any change should include an impact analysis. How will the change affect the
scope, time, cost, and quality of the goods or services being provided?
 Changes must be documented in writing. Project team members should also document all
important meetings and telephone phone calls.
 Project managers and teams should stay closely involved to make sure the new system will meet
business needs and work in an operational environment.
 Have backup plans.
 Use tools and techniques, such as a contract change control system, buyer conducted performance
reviews, inspections and audits, and so on.

Closing the Contract

 Involves completing and settling contracts and resolving any open items.
 The project team should:
 Determine if all work was completed correctly and satisfactorily.
 Update records to reflect final results.
 Archive information for future use.
 The contract itself should include requirements for formal acceptance and closure.

65
Tools to Assist in Contract Closure
 Procurement audits identify lessons learned in the procurement process.
 A records management system provides the ability to easily organize, find, and archive
procurement-related documents.

Using Software to Assist in Project Procurement Management

 Word processing software helps write proposals and contracts, spreadsheets help evaluate
suppliers, databases help track suppliers, and presentation software helps present procurement-
related information.
 E-procurement software does many procurement functions electronically.
 Organizations also use other Internet tools to find information on suppliers or auction goods and
services.

66