UNIT - II

Disclaimer:
The lecture notes have been prepared by referring to many books and notes prepared by the teachers. This document does not claim
any originality and cannot be used as a substitute for prescribed textbooks.
 Topics
• IT Project/Service Management
• Planning
• Estimating
• Resourcing
• IT Project/Service Change
• Quality
• Issue
• Risk Management
• Evaluate issue and mitigate risk in IT Service
Management
 IT Project/Service Management
• The word ‘project’ came from the Latin word projectum from the Latin verb proicese (to
throw something forwards) which in turn comes from ‘pro’ which denote something
that proceeds the action of the next part of the word.
• A project is a combination of interrelated activities with well defined objectives
to be completed in a specific time period.
• Project is something special which is different from routine and regular
activities
• According to Harrison, “Project is a non routine, non repetitive, one-off
undertaking, with well defined time, financial and technical performance goal”
• According to Project Management Institute (PMI), “Project can be defined as a
temporary endeavor undertaken to accomplish a unique objective at goal.”
• Examples of Project
– Construction of a house,
– Writing a book,
– Building a dam,
– Introducing a new product in the market,
– Construction of a new bridge over a river,
– A Politician contesting an election,
– Organizing a seminar.
 IT Project/Service Management
Difference between Projects and Regular Operations

Projects Regular Operations

• One Time • Repetitive

• Use of wide variety of skills • Limited Skills
• Use of special purpose • Equipments are in
equipment for short continuous use
duration
• No revenue during Project • Revenues are there
stage
 IT Project/Service Management
Characteristics of a Project
• Well defined objectives
• Uniqueness (Non-routine activity)
• Complexity (Demands team work)
• Life cycle
• Risk and uncertainty Change (In response to environment)
• Non Recurring
• Duration of activities
• Uncertain - Completion deadline
• Optimality
• Multidisciplinary & Interdependencies Forecasting
• Definite time limit
• Team work
• Conflict for resources
• A separate disposable team
• Performance measurement
 IT Project/Service Management
Taxonomy of Project
• Based on the type of activity
• Based on the location of the project
• Based on the completion time
• Based on ownership
• Based on size
• Based on need

Types of Projects
• Construction projects
• Research projects
• Reengineering projects
• Procurement projects
• Business implementation projects
• Miscellaneous types
 IT Project/Service Management
Project Management

MANAGEMENT
Knowledge, skills, tools and techniques

PROJECTACTIVITIES
Conception, design, Implementation, Commissioning
Project Management

Project Management
SUCCESSFUL PROJECT
Within planned time, resource, scope and quality
 IT Project/Service Management
Project Management
• Project Management is a system of procedures, practices, technologies and know
how that enables the planning, organising, staffing, directing and controlling of
project activities to successfully manage a project.
• It may be described as planning ,organizing, staffing ,directing
International
and controlling
some part of the organization for relatively short period of time to achieve the
project objectives with in laid down constraints
• It is defined as “The application of knowledge, skills, tools and techniques to
project activities in order to meet project requirement.”
• “ Project Management is the art of directing and coordinating human and material
resources throughout life of a project by using modern management techniques to
achieve pre-determined objectives of scope , cost , time, quality to the equal
satisfaction of those involved.”

Why Project Management Major

• Interdependency and complexity
• Sharing of Resources
• Size of Project
• Importance of the Project
• Changes in the market
 IT Project/Service Management
3 W’s of Project Management
• What: Scientific application of modern techniques and tools.
• Whom: In planning, financing, implementing, monitoring, controlling and
coordinating unique activities of project
• Why: To produce desirable outputs in accordance with predetermined
objectives within constraints of time and cost.

Project - Scope Triangle

Cost Time
Project
scope and
quality

Resources
Resour
 IT Project/Service Management
Project Parameters
• Defining project scope
• Defining quality
• Managing time
• Managing cost International
• Managing resources

Benefits of Project Management

• Clear description of work to be performed
• Responsibilities and assessment of tasks
• Time limit for task completion
• Measurement of accomplishment against plans is possible
• Problems are exposed in advance allowing corrective action
• Objective that cannot be Major
met are identified early
 Project Management Process
• Three phases - planning, monitoring and control, and closure
• Planning is done before the main engineering life cycle (LC) and closure after the LC
• Monitoring phase is in parallel with LC
• Planning is the process of stating objectives and then determining the most effective
activities or accomplishments necessary to reach the objectives.
• Basic objective:
– To create a plan to meet the commitments of the project
– create a path that, if followed, will lead to a successful project
• Planning involves
– defining the LC process to be followed, estimates, detailed schedule, plan for quality,
etc.
• Main output
– a project management plan, and
– project schedule
 Responsibility of the Project Manager
 The Project Manager needs to manage upwards - ensuring that the inverted
hierarchy comprising the organization's leadership and the project sponsors are
doing all that is required to guarantee the success of the project.
 The Project Manager needs to manage upwards - ensuring that the
inverted hierarchy comprising the organization's leadership and the project
sponsors are doing all that is required to guarantee the success of the
project.
 The Project Manager is also the main focal point for liaison with other
departments, projects and initiatives within the organization, taking into account
the needs and contributions of other internal groups.
 The Project Manager is at the centre of everything relating to the project.
Controlling the contributions of seniors and peers is just as important as
managing the work of the team.
 The Project Manager is equally the main point of contact for aspects requiring co-
operation and co-ordination with external parties such as the project's suppliers
and contractors, customers, suppliers, regulatory bodies, and other third parties -
making sure everything is in place to guarantee success.
12
 Responsibility of the Project Manager
The Project Manager has direct responsibility for the activities of all project
participants, all project tasks and all deliverables - whether directly or indirectly. It
is not like a typical hierarchical line management role.
 Bear in mind that the Project Manager needs to achieve this without direct
control over the participants.
 The Project Manager will not have power over the leadership, nor the
internal and external contributors. Even in the project team there may be
loaned staff, part-timers and sub-contractors who will have their prime
loyalties elsewhere.

The Project Manager is responsible for everything that

is required to make the project a success

13
 360o Responsibility of a Project Manager

Leadership Team
Steering Group
Project Director
Sponsors
External Liaison
Internal Liaison
Project Trading Partners
Line Departments
Manager Suppliers
Other Projects
Contractors
IT
Project Team
Participants
Deliverables
Tasks

Project management is a specialist discipline.

In a well run project, there is a constant array of management
issues to deal with, as well as a challenging routine of project
management processes.
14
 360o Responsibility of a Project Manager
Stress that the project manager is the person accountable for the project.
The project manager acts as the single point of contact for the project.
The project manager is responsible for identifying project stakeholders.
- A project stakeholder is a person with a role or interest in the project.
Note that the project manager is the individual responsible for:
Planning and organizing the project
Managing its day-to-day activities
Delivering the project deliverables to the client or project sponsor
Teach to the role of the project manager, not the title. The project manager might
also be called a project leader, project executive, or other title.
It is essential that students understand that the term project manager as used in
this course is a Role as opposed to a Position. Thus, a project manager may be
managing a proposal, a project, a negotiation, and so on.

Additional Information:
The project manager is responsible for the project's technical activities and project
management activities.
15
 360o Responsibility of a Project Manager
Additional Information:
The project manager must manage triple constraints:
- Making sure the project meets requirements
- Making sure the project is completed on time
- Making sure the project is completed within the budget
While managing these constraints, the project manager must also achieve client
satisfaction.
Stress the inherent problem of being caught between the client or project sponsor
and their company. Blowing a budget in a fixed-price contract may result in a happy
client or project sponsor, but may not meet company's goals. The opposite occurs
in a time-and-materials contract.
The project manager is responsible for organizing the project team, providing
project documentation, and developing procedures.
- The project team comprises individuals across the company, clients/project
sponsors, and suppliers. It is composed of people from various disciplines (for
example, marketing, finance, services, manufacturing, engineering, architecture,
sales, development, clients/project sponsors, and suppliers). It is possible that there
may not be any project team members from a project manager's own organization.
- Documentation includes the contract file, project plans, project procedures,
financial documentation, and correspondence. 16
Project Manager is a Single Point of Contact

17
 Project Manager is a Single Point of Contact
Details:
The project manager plans, manages, monitors, and controls the project.
The client ensures the project plan and deliverables meets their needs and
requirements.
The project sponsor monitors the project's status, approves final
deliverables, and authorizes the release of funds.
Team members complete the project activities in accordance with the
project plan.
Support groups provide ongoing support to ensure the project progresses
smoothly and successfully.
Subcontractors perform purchased services, such as network
administration or media production.
Senior management acknowledges and promotes the project.
Additional Information:
 Teach to the role of the project manager, not the title; the project
manager may be called a project leader, project executive, or other title
(such as PDT head or team head).
 Project management may be done by a team.
18
 Project Manager is a Single Point of Contact
Additional Information:
 Note that the people on the visual are possible project stakeholders.
There may be more. The project manager must find all the stakeholders.
 Ask the students why the project manager is the single point of contact
and, what the consequences would be if he or she were not.
 Note that the project manager is the individual who is responsible for:
- Planning and organizing the project
- Managing its day-to-day activities
- Delivering the project deliverables to the client/project sponsor
 Emphasize that the clients/project sponsors are most influential. Without
them, there is no project.

19
 Project Planning
• Project planning is done to have an understanding of how the project will be executed
and managed.
• It highlights the core areas such as project budgeting, project risk management, project
quality and more.
• The project plan must have all the answers to explain the execution, management and
control of the project.
• It is essential to have project planned beforehand to achieve project’s objectives.
 Project Planning
Key planning Tasks
• Define suitable processes for executing the project
• Estimate effort
• Define project milestones and create a schedule
• Define quality objectives and a quality plan
• Identify risks and make plans to mitigate them
• Define measurement plan, project-tracking procedures, training plan, team
organization, etc.

Who makes the plans?

• Everybody must plan
• Project manager must initiate the planning process
• Project manager coordinates planning activities into the overall project master plan

Characteristics of a Project Planner

• Flexible
• Creative
• Responsive
• Communicative
• Analytic
 Planning strategies
• Planning a project is where the Project Manager must bring together the
complete understanding of the project's requirements with a deep
understanding of all the elements that are required to conduct a successful
project.
• In many ways, it is the centerpiece for the Project Manager's skills. Of course, it
all counts for nothing unless it leads to a successful project!
• Planning, estimating and resourcing may be viewed as separate issues, but they
need to be conducted in parallel as they directly affect each other.
 Planning is the definition of work to be done, including resource requirements,
dependencies and timing.
 Estimating is the calculation of the amount of time and effort that will be required
per type of resource for each part of the work to be done.
 Resourcing is the allocation of actual resources (usually the project's workforce) to
the plan. The availability of resources will always be limited. Resources may
be required in greater quantities than are available or have competing
demands on their time. It may be necessary to make compromises or move
work between different potential resources to make best use of the resources
available. 22
 Top down or bottom up?
The classic approach to planning is top-down.
• We divide all the things required into a few high-level items then, explode them
into greater levels of detail as the planning process proceeds. Very often this
explosion stops at a relatively high/summary level of detail for the initial planning
and is only expanded into full detail shortly before each new phase of work.
• Top-down is the most logical way of thinking about a project and is usually the
best approach to new endeavors. It provides an early high-level plan, including
initial costs and timings, which can be used in the project's definition and benefit
case.
• Bottom-up planning makes sense where we already have a good example of a
successful similar project plan to base the new project on.
• A majority of projects will be similar to something that has been done before and
it makes sense to use that as a starting point (assuming it was of good quality). As
well as saving time in the planning process, this allows us to learn lessons from
the previous experiences. In particular, estimates can often be extrapolated from
the previous projects.
 Top down or bottom up?
• In bottom-up planning we start with the full detail of a previous plan and adjust
the precise details, estimates and dependencies to be correct for the new project.
• From the beginning, we have a fully detailed plan. This usually means that where
top-down plans need to be exploded, bottom-up plans need to be summarized so
that they can also be used at a summary level for things like the project
definition, benefit case, and reporting.
 All in one go or exploding detail in stages?
• Where you have started from a detailed plan and worked bottom-up, you
already have the full detail - but remember to review that detail as you progress
through the project as things will inevitably change.
• You may choose to review the detail in stages in a similar manner to the way you
would deal with a top-down plan.
• If you started with a top-down plan, the question is - when should you explode
it into full detail? If it is a relatively simple project, with short timescales and a
manageable number of resources, you may easily be able to generate a
sufficiently detailed plan at the beginning of the project and stick with it
(bearing in mind that the Project Manager has a continuous duty to make sure
the plan is realistic).
• In larger projects, best practice is to explode the detail in stages. Here are
some of the reasons why:
– No one needs to know precise details so far in advance that it is of no consequence.
– Giving precise detail too far in advance inevitably means it will be wrong -
some of the people reading the plan will not realize that and those that do
may think you are stupid for being so accurate.
25
 All in one go or exploding detail in stages?
• In larger projects, best practice is to explode the detail in stages. Here are
some of the reasons why:
• You have more important things to be doing with your time during the
definition and launch of a project than worrying about the precise timing of
events in the distant future.
• Clearly, you need that detail far enough in advance to make decisions about the
allocation of individual people to tasks and to mobilize the resources required.
• You should also plan out the detail for logically complete elements of the project
together so that all related issues are examined together.
• Very often this means that detailed plans are best prepared per phase during
the project.
• The first phase of work would be planned immediately following the project
definition. Further planning for following phases would be done towards the
end of each phase to give a reliable base for the starting dates and any
variations in the originally planned activities.
• It must, however, be done early enough that the required resources can be
identified and mobilized in time for work to commence.
26
 Fully detailed or streamlined / summary?
Given that the full detail is largely for the Project Manager's benefit - how do you
make that choice? Here are some of the factors to consider:
Factor Small plan Large plan

Constructing the plan Low effort / short time High effort / long time

Will be at a high level hence may be Can be fine tuned for perfect
Identifying dependencies
inefficiencies and missing links automatic scheduling

Probably need to assign groups of people Can accurately assign individual

Identifying resources
to deliver high-level tasks collectively people to individual tasks

Probably insufficient detail - you will be

Telling people what to do Should all be in the plan
relying on "word of mouth"

Low effort but possibility of issues being

Tracking progress High effort - but accurate
hidden

Will need to be summarized for

Reporting progress May be usable without summarization
reporting purposes
27
 One plan or several sub-plans?
• The Project Manager will need to consolidate the plans for the overall
estimating and scheduling of the project.
• Particular attention should be given to issues between the sub-plans, for
example:
• identifying and working to overall project milestones,
• cross dependencies,
• scheduling and contention when the same resources are used in more than one
sub-plan,
• ensuring compatibility and standards.
• The ease with which the project can be handled as a number of sub-plans often
depends on the choice of automated project planning tools.
• The best (i.e. most expensive) tools will have no trouble consolidating and
scheduling multiple plans.
• Some of the more basic software tools have limitations that might lead the
Project Manager to prefer to represent the sub-plans as separate sections within
a single physical plan.
28
 One plan or several sub-plans?
• A good way to deal with complexity and with unwieldy large plans is to use a
number of sub-plans.
• There will be one overall plan showing the whole project, but for its detail it will
link to various sub-plans.
• The sub-plans would deal with various subsets of the overall project, for
example, there might be one per work stream or one per sub-team.
• Ideally, each sub-plan will have its own Team Leader. That Team Leader will have
responsibility for delivering against the sub-plan and would often be given the
job of developing the detail during the planning stages.

29
 Philosophy of Different Plans
Style For Against
It's what many people are Can seem like a lot of work is
Activity familiar with - instructions that done without creating any
focused tell them what they have to do tangible, measurable result
Process Very good at explaining how Loses the staged view of the
focused things are done overall project
Might focus attention on trivial
Deliverable Focuses attention on delivering or artificial outputs instead of
focused the deliverable the major focus of the work
Can seem esoteric and can be
Outcome Focuses attention on what really hard to measure that the
focused counts outcome has been satisfactorily
achieved.
In reality is focused on
deliverables or outcomes as
Milestone Presents a simple picture described above. Will not
focused focusing on critical information. normally focus attention on the
path or effort to attain each
milestones.

30
 Philosophy of Different Plans
• An ideal approach would be to hold all these differing views and criteria in a
multi-dimensional model of the project whereby the Project Manager can view
and present the plan in any of these manners.
• Unfortunately the workload to create and manage plans would be high if not
prohibitive and the software tools do not exist to make it possible.
• A good plan will, nevertheless, be organized so that the major activities, work
streams, deliverables and outcomes are all apparent to the reader whichever
main structure has been chosen.
• The classic and common understanding is that a plan tells you what things to do.
• It describes the various activities that are required. These would typically be
broken down and structured into categories for ease of understanding.
• This is a basic concept in Project Management - the Work Breakdown Structure
(WBS) .

31
 Work Breakdown Structure (WBS)
• A Work Breakdown Structure (WBS) A deliverable-oriented hierarchical
decomposition of the work to be executed by the project team to accomplish
the project objectives and create the required deliverables; it organizes and
defines the total scope of the project
• Each descending level represents an increasingly detailed definition of the
project work
• The planned work contained within the lowest-level WBS component, called
work packages, can be scheduled, cost estimated, monitored and
controlled
• The deliverable orientation of the hierarchy includes internal and external
deliverables
• Work not defined in the WBS is outside the scope of the project.
Details — A WBS contains all the external and internal work products of the
project. External products are delivered to the customer. Internal products are used
internally on the project but are not given to the customer.

Note: The WBS is the heart of the project manager's planning 32

database
 Work Breakdown Structure (WBS)
Details — A WBS is made up of work components, or units of work. The tasks
should be decomposed to the level where one person is responsible, the work unit
can be accurately estimated, and is a size that can be managed and controlled.
Additional Information:
• The WBS is a deliverable-oriented structure of the work to be done, so verbs are
used.
• The WBS presents all the work on the project that affects cost, schedule, or
specifications.
• The Project Management Institute (PMI®) defines the WBS as "Deliverable-
oriented grouping of project components to organize and define the total scope
of the project; work not in the WBS is outside the scope of the project.“
• A WBS can be tailored, depending upon its intended use.
• Ask students how many have actually built a WBS.
• Note that a WBS might or might not have the same number of levels.
• A WBS identifies what needs to be done in order to create deliverables. That's
why verbs are used, for example, build, test, create, design, install, and ship. 33
 Work Breakdown Structure (WBS)
Additional Information:
• Remember to tell students that work packages can occur at different levels.
Work packages are the lowest level of any branch and are always the most
indented and the most numerous. A work package is a required task for
completing each product.
• PBS is the product breakdown structure of the deliverables, rather than work
performed. A PBS represents a product and all of its subproducts.

34
 When Is a WBS Created?
• The WBS is generated after the team understands the work products to be
developed
• Development begins when deliverables are identified and agreed to by the
sponsor
• From this point in project planning, the project scope can be described in
measurable and discrete work efforts
• The WBS is used throughout the project as a tool for communication, and it
grows and develops with the project from the first day
• If the project plan is revised, the WBS must also be revised
Details — Two points should be clear now:
• The work could not be broken effectively into component products and tasks
prior to the Identification and validation of project requirements.
• Without some change control, it would take forever to complete the WBS.

The approved detailed project scope statement and its associated

WBS and WBS dictionary are the scope baseline for the project 35
 When Is a WBS Created?
Details
• This is the point in project planning when we can describe the scope of a
project in measurable and discrete work efforts.
• The WBS should be developed as soon as the work products are identified and
agreed to by the client/project sponsor.
• The WBS is used as input to the planning process from the beginning of the
project. The WBS is the foundation for the work of the project.
• Any time anything changes on the project, such as scope, resource, schedule,
and cost, the WBS must be revised first. The WBS changes with the project; it is
not just created once and filed away.
Additional Information:
• The WBS serves as the foundation for the rest of the project in terms of
planning and budgeting, funding, estimating, scheduling, risk management,
performance measurement, and change management.
• Discuss when to use the WBS—on the first day of the project as part of the
planning process!
36
 When Is a WBS Created?
Additional Information:
• But, whenever the project plan is revised, the WBS must also be revised.
• Discuss how the WBS is used as a communication tool and as a performance
measurement tool throughout the project.
• The WBS is not just created and then filed away, but instead grows and
develops with the project from day one to the end of the project. As the project
ages, so does the WBS.
• Explain that many organizations have standard templates for WBSs, and often
WBSs can be reused because many projects resemble other projects to some
degree.
• There is a two-way relationship between the organization and the WBS for
consistency and also between the WBS and plans, reviews, and documentation.
• The WBS serves as the basis for status reporting, cost estimating, and the
development of the project schedule.
• The WBS can be viewed as the heart of the project manager's planning
database.
37
WBS Relationships

38
 WBS Formats and View

WBS Formats
WBS View

39
 WBS Development Guidelines
 At startup, gather all current baseline materials and project-related information,
such as:
 Project definition document
 Statement of requirements
 Technical proposals
 Supplier proposals
 Conduct a workshop with key people
 Concentrate only on Level 2 or 3 of the WBS
 Use Post-it notes rather than a flipchart, white board, or PC planning tool
 Push responsibility down to those who will be responsible for the work package
 Document each work package, including its completion criteria
Details — Guidelines for nodes:
 Each must consist of no more or less than sum of the nodes connected below it.
 None may duplicate or overlap each other.
40
 WBS Development Guidelines
Details — Guidelines for nodes:
 Each must have verifiable completion criteria.
 Each must have a single party responsible for its attainment.
Guidelines for size:
 Restrict the number of levels to a minimum of 5 but less than 15.
 Ensure there is a range of no more than 10 elements at any level.
Numbering standards:
 Note the potential for change and how it might affect the breakdown structure in
selecting a numbering system.
 Consider that many planning tools automatically number the levels.

41
 The “Shape" of a Project
• Projects can have any number of different shapes.
• By shape we mean the way the different elements are structured and how they
relate to each other. An IT strategy project does not look like an eCommerce
project, which, in turn, does not look like an ERP package implementation. It is
more than just a question of what we are trying to achieve - it is also a question
of how we will go about it. How do you explain the shape of a project?
• Where you plan to use a predetermined methodology for the work, the shape
will be defined by that methodology. For example:
• Does it do it in three phases, four phases, five, six, seven, eight?
• What is the size of each phase?
• Does it have waterfall phases, overlapping phases or iterative phases?
• Alternatively, you may find you are free to make these choices for yourself.
• Probably the easiest way to explain the shape of your project is using a
graphical presentation. Let's start by looking at an example. Study this carefully
and see if you can deduce all the messages it is trying to communicate before
looking at the explanations.
42
 Explaining the shape of a project
• There are seven
logical, overlapping
phases (it is not
a waterfall).
• There are three main stages
- agreeing the conceptual design,
building the solution, and operating that solution.
Here's what we were trying to say:
• There are seven logical, overlapping phases (it is not a waterfall)
• There are three main stages - agreeing the conceptual design, building the
solution, and operating that solution; key reviews would be held to decide
whether to proceed.
• The first stage delivers a conceptual design - Early focus is on defining and
agreeing the vision for this undertaking. These thoughts continue to evolve up
to the finalization of the conceptual design. 43
 Explaining the shape of a project
Here's what we were trying to say:
• Once the initial vision is substantially in place, attention then moves to defining
how the project should achieve it.
• In turn, as this becomes clear, work increasingly focuses on producing the
overall conceptual design.
• The second major stage delivers the working solution. It is a much larger
amount of work and a longer timescale.
• An iterative prototyping approach will be used, so design work and
development work are interlocked
• Around "live date" the final formal testing and acceptance will take place.
• At the same time, the project team and user community is preparing
intensively for implementation and live running.
• We are also building up for routine operation, maintenance, support and
enhancement.

44
 Evolution of Software Development Models
Traditional development phases
• Software development models have evolved over time.

Requirement Release and

Analysis Design Implementation Verification maintenance

Waterfall (years)

Iterative (weeks)

Continuous delivery (hours)

• The traditional development process is divided into phases.

• These phases, as shown in the diagram, go from analysis to design and
implementation to verification to release and maintenance.
• Almost all development processes have these steps. The big difference is
how long it takes to complete all of these steps.
• The diagram shows 3 kinds of development models and the cycle time
45
associated with them.
 Evolution of Software Development Models
Traditional development phases
• Waterfall originates in the manufacturing and construction industries.
Software is ready for release when all of the functionality for the release has
been developed. This development process is typically measured on years.
• Agile introduces the idea that the team should get their software ready for
release throughout development. Many variations of agile do this in “sprints”
(periodic intervals). Agile processes are typically measured in weeks.
• Continuous Delivery is another subset of agile which in which the team
keeps its software ready for release at all times during development. It is
different from “traditional” agile in that it does not involve stopping and
making a special effort to create a releasable build. Continuous delivery
models are typically measured in hours.
• With each of these development models accessibility is critical.
• The question is how to integrate accessibility into each of these development
models. Including accessibility into longer processes is relatively well-known.

46
 Comparing with Agile Methodology

• Let’s answer the question, what is agile methodology? This slide shows a
diagram comparing traditional waterfall methodology on the right with agile
methodology on the left.
• The waterfall methodology is characterized by rare release events. These events
47
are greatly spread out over time.
 Comparing with Agile Methodology
• The diagram shows that there is a lot of effort, or a lot of change in the product,
as it moves from pre-release to a release stage. This great difference in change,
and great difference in effort to achieve the change, results in effort peaks and a
much higher risk.
• In contrast the agile methodology is characterized by frequent release events.
These events are quite compressed in time. And the effort to achieve each
release and the associated change as it moves from prerelease to release, is
much smaller. This results in smaller effort peaks, a smoother effort, and much
less risk.
• As mentioned, agile processes are often measured in a few weeks. These are
sometimes referred to as “sprints”. A typical Sprint may be 3 to 6 weeks.
• The big question is when teams are used to long cycle processes, such as the
traditional waterfall, where accessibility is often addressed as secondary
function, and often later in the development process, under such circumstances
how does accessibility fit into a more frequent release cycle? How should
accessibility best be adapted to an agile process?

48
 Scheduling
• The basic things we need to identify are:
• when does a piece of work start, and
• how long does it take?
• When it starts will be calculated primarily by its predecessor dependencies,
plus the need to smooth out the usage of resources.
• Planning tools normally include complex logic to calculate the optimum
schedule - but, as we discussed earlier, they may take some manipulation to
give optimum results.
• You can often tell whether a plan was scheduled automatically simply by its
appearance. Automatic scheduling often appears crazy but gives optimum
results. Manual scheduling looks far too neat and orderly to have been
calculated by a computer.
• How long it takes can be calculated as:

Duration = required effort / resources applied

• The thing that makes this sometimes difficult is that there are three variables:
duration, effort and resource. It is a three way balance that you have to
49
achieve. Here are some examples:
 Scheduling
If we are estimating the duration of a task to type in all the product information for
the product catalogue, maybe the calculation is:
 Duration = 20 days effort divided by 5 people = 4 days
If we double the resources, we can get it done faster:
 Duration = 20 days effort divided by 10 people = 2 days
Suppose, instead, that we are scheduling a 4 day training course for the project
team. If we decide to assign twice as many people it does not become a 2 day
course ---- it is the effort figure that changes.
 Effort = 4 days duration for 10 people = 40 days effort

Very often, however, you know exactly how many resources you have - so that
remains a constant. I only have 4 of this type of resource available, so if the job
takes 20 days effort ---- it will last 5 days
 Duration = 20 days effort divided by 4 people = 5 days

In each calculation, we tend to lock one of the variables, input something that is
variable, and thus re-calculate the third variable - otherwise a formula in the form
D=E/P would have infinite solutions. 50
 Scheduling
• Bear in mind that this simple arithmetic tends to ignore other complications.
Consider whether it is valid in these cases:
• What if we assigned 160 people to the task - could they have that catalogue
ready in 1 hour?
• Assuming we have eight months before the catalogue is needed, would it make
sense to assign the same task to one person for just one hour a day?
• If the 20 days effort were spent on a "Conference Room Pilot", where people
discuss design options and try them out, would 10 people in the room instead of
5 make it twice as quick or twice as slow - or even worse than twice as slow?
Take a look at the discussion on "complexity" if you are not sure.
• This arithmetic and logic is more complicated where multiple resources are
assigned to multiple tasks, potentially at the same time (but that will depend on
the detailed scheduling), in differing proportions. For example:
• Duration = 100 days; Effort = 60 days comprising...; Project Manager 10 days
effort ==> resource level of 10%; Project Administrator 50 days effort ==>
resource level of 50%
51
 Scheduling
• So, the Project Manager needs to be available one tenth of the time on average
and the Project Administrator needs to spend half time on this work.
• The duration of the work will be defined by whichever resource takes the
longest to do their proportion.
• In this case, we would want to balance their effort and availability figures so that
they both work at the tracking task for the full duration of the project. In other
cases, it may be one specific resource that is holding up completion.
• Bear in mind also the pitfalls you might discover, particularly with automated
scheduling, and the various tricks you might need to play to avoid them (as
described earlier).
• What do you think would happen to this Project Tracking task if the Project
Manager had to work full time on a different task for a period of 10 days in the
middle of the project?

52
 What Is a Schedule?
• A Schedule is any plan structured on a time dimension, including a project
management schedule, financial plan, operational schedule, and staff
schedule
• A Project management schedule is a road map of a project that states the
duration and sequence of events and activities; more specifically, it states
what is done, when it is done, and who is responsible
• It is composed of estimates, work products, activities, and tasks from
the WBS, and resource information
• A schedule also contains the planned dates for performing activities and
meeting milestones and defines how the current project interlocks with
other projects
• A project management schedule can be represented in a variety of
ways; three of the most common are precedence diagram, Gantt chart,
and milestone chart

Schedules are key management tools for tracking & communicating progress of a project
53
 The Purpose of Scheduling
The Project Schedule is used to:
• Track the planned versus actual progress of your project and show your team
and your sponsor how the project is progressing
• Evaluate the planned versus actual progress of your project, and determine
whether to revise the project to meet major milestones and completion dates
• Determine whether to accept or reject a change based on how it affects the
sequence of tasks, resources needed, staff responsibilities, major milestones
and project completion date
Communicate the Project's status to all parties about issues such as:
• Whether the tasks and activities are likely to result in successful project
completion
• When resources are needed for the project
• What the major milestones are and when they occur
• The critical path, the series of activities that determines the duration of the
project
54
A schedule is the planned dates for performing activities and for meeting milestones
 Basic Scheduling Terminology

Task A task is a subdivision or portion of an activity; it describes the lowest level

of the WBS
Activity An activity is an element of work performed over a period of time within the
project; it is a specific piece of work in the WBS which has a measured
beginning and a measured end
Event Specific points in time, starting and ending points of actives, typically
represented by circled numbers in a schedule

Milestone A milestone is an achievement or a significant event in the project or

subproject, such as a major decision or completion of an important activity;
it is an activity that has zero duration and zero resources
Precedence A precedence relationship is a dependency between two activities, or
relationship between a project activity and a milestone

Precedence The precedence diagramming method (PDM) is a means of constructing a

Diagramming project network diagram using nodes to represent activities and connecting
Method (PDM) them with arrows to show the dependencies; also referred to as an activity-
on-node (AON)
Project Network A project network diagram is any schematic display of the dependencies
Diagram among project activities

55
 Basic Scheduling Terminology
An example of an event is Start code development.
• Provide additional information about a milestone so that it is not solely an
abstract definition.
• Stress that a milestone is a marker. Milestones can have owners and can appear at
the task level in some software tools.
• Stress that milestones are flashes or instants in time that mark significant events.
- For instance the kickoff meeting is not a milestone. However, the kickoff meeting
completion is a milestone.
• Ask how the milestones above might be used.
- Task 1 complete could be a milestone that provides incentive for the employee
working on it.
- 200 million yen spent might be a significant milestone if it represents a
significant portion of the budget.
- Phase 1 complete, and client/project sponsor acceptance attained, can serve as
markers within the project.
56
 Basic Scheduling Terminology
An example of an event is Start code development (Contd).
• Explain that identification of project milestones depends on who is interested. For
senior management, there may be only a few milestones, even in large projects; for
the project manager, there may be many critical points in the project schedule
when major decisions must be made, large changes to the resource base must be
initiated, or key technical results must be achieved. Milestones are the key events
that serve as a focus for ongoing control activities. They are the project deliverables
in the form of in-process output or final output.
• Clients, project sponsors, or upper management; might be interested only in
major milestones, and as such you may need to create the milestone chart. Ask the
students for examples of milestones of interest either to clients/project sponsors or
upper management. Examples: upper management— payment schedule;
client/project sponsor—deliverables, payment, measurement of progress.
• Lag should never be rolled into the task, as it represents the fixed delay between
the start or finish of one activity and the start or finish of another.

57
 Delivering business value is hard…

• “Of the work executed: “Many (possibly

most) organisations lose as much as 45% of
their total revenues due to costs associated
with low quality”
– Six Sigma

• “Some 75 percent of most large-scale J2EE

projects fail by missing both time and
budget projections …”
– Mark Driver, Gartner

• “64% of features actually delivered are

either rarely or never used”
– Jim Johnson, Standish Group

58
 Brief History of Development Methodologies
AGILE e.g. XP
(Kent Beck)
Methodologies Incremental, user
driven, low process
RUP (Rational)

Object oriented,
iterative, time-boxed,
user driven
RAD
(James Martin) RUP

Prototyping,RAD
SPIRAL MODEL
iterative, time-boxed,
WATERFALL (Royce) (Barry Boehm)
user driven
Requirements, design Iterative Spiral Model
implementation,
verification & V-MODEL (Anon)
maintenance
Waterfall Aligns testing V-Model
to
Waterfall
development

1960 1970 1980 85 91 98 99

59
 Agile Misconceptions?
• Agile means: “letting the programming team do whatever they need to with no
project management, and no architecture, allowing a solution to emerge, the
programmers will do all the testing necessary with Unit Tests…”

60
 What is Agile?

• We are uncovering better ways of developing software by doing it and helping others
do it. Through this work we have come to value:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

• That is, while there is value in the items on the right, we value the items on the left
more.
Management can tend to value the things on the right over the things on the
left
http://www.agilemanifesto.org/

61
 Agile project management - SCRUM

Daily Scrum Meeting:

15 minutes
Team-Level Each teams member answers 3
questions:
Planning Every 24hrs 1) What did I do since last meeting?
2) What obstacles are in my way?
3) What will I do before next meeting?

Every Iteration
4-6 weeks

Prioritised Working
Iteration Software
Requirements
Scope Delivered

Prioritised
Requirements &
Requirements
Requirements Features “Backlog”
Requirements
Requirements Applying Agile: Continuous integration; continuously monitored progress
62
 Don’t do this – if you want to fail

• Use integrated teams

• Sort out the development environment early

• Choose tools carefully

• Enterprise architecture is important for large/long lived systems

• One person needs to own the process vision with support from many

• Use partners experienced in the method

63
 Estimating - Why, What, How?

• There is a belief that Project Managers of business solution and IT projects are
not very good at estimating, unlike their counterparts in construction projects.
• There is an error in this belief - according to several construction Project
Managers, they are not particularly accurate either.
• There are many theories and approaches but no fully reliable way for predicting
the time and effort it will take to deliver a business solution.
• When you bear in mind the complexity of any business solution and the dramatic
variance in individual productivity, you can understand why it cannot be an exact
science.
• Some IT developers seem to be able to create systems as fluently as they speak
their mother tongue. Others, maybe sitting at the next desk, struggle to deliver.
• There can be a factor of 10 to 1 in personal productivity between the best and the
worst. These are just a few of many factors.
• We will take a look at several key issues then summarize the drivers of effort.

64
 Definition of Estimating
 Is the process of determining effort, duration, and costs for the elements in the
WBS
 Is the process of identifying what resources are necessary for each work package
 Is the process of identifying the should cost for each project task and activity
 The following terms are key parts of estimating:
 Effort is the number of labor units required to complete a task. It is usually
measured in staff hours, or person-hours
 Level of effort (LOE) describes the activities that are necessary to support a
project that cannot be scheduled
 Duration is the number of work periods, excluding holidays or other
nonworking periods, required to complete an activity or other project element

Estimating is done as early in the project life cycle as possible

and is normally repeated a number of times throughout the life
of the project as changes in the project dictate
65
 Definition of Estimating
Details:
 Review the definition. Inform students that estimating is the process of identifying
effort, duration, and costs for each work package. Estimating enables you to
determine effort and duration for the elements in the work breakdown structure.
 Explain how budgeting is different. Budgeting is the allocation of the should cost
over the time period required to do the work. The estimate provides the should cost
for the task or activity, but further analysis is necessary to determine the specific
time period needed to perform.
 Time periods can be hours, days, weeks, or months depending upon the complexity
of the task, activity, or work product. After the should costs have been spread out
over time according to when the work is to be performed, the project manager must
develop a time-phased cost baseline that becomes the plan-of-record cost to a work
package.
 It uses the estimate to determine how much money is allocated to each work
package. This enables project managers to develop a financial measurement baseline
that is then used to track and control the execution of the project.
66
 What an Estimate Is
An estimate is:
• An assessment of the likely quantitative result
• Usually applied to effort, project cost factors (labor hours or money, or both)
and the schedule (duration)
• Used with an indication of accuracy (for example, + n percent)
• Usually used with a modifier (for example, preliminary, conceptual, feasibility, or
final)
• Completed at a level that is appropriate for the decisions being made with the
data (for example, close-in estimates are more detailed than those for periods
three to six months in the future)

An estimate is just that--an estimate.

The only perfect estimate is the one done after the work is completed!

67
 What an Estimate Is
• Estimates are not based solely on effort in hours, they must include all elements
related to the cost of the project, including resources such as:
• Staff
• Facilities
• Materials
• Direct costs
• Indirect costs
• Duration of tasks
• An estimate is an assessment of the likely quantitative result. It may also be
defined as: An approximate judgment of the effort, cost, and time scale to
perform a piece of work
• A quotation for a piece of work that cannot be executed without notice being
given
• A documented statement of the resources needed to complete a project
• A document containing resource information including resources needed, who
will supply them, when they are needed, and how long they are needed 68
 What an Estimate is NOT
• An estimate is not:
• An accounting or marketing strategy
• A pricing approach, because the price might or might not accurately reflect
the estimate
• An investment approach, because it is not worth taking a risk today to get
business later
• A way to ensure sponsor satisfaction, such as arbitrarily reducing your
estimate to meet some implied number (you must present reality)
• Software or tools
• Finding the fastest way (The schedule should not unduly influence the
estimate--be realistic and honest)
• Discuss that an estimate is NOT a budget. Make sure students understand the
difference. Cost estimating is defined as estimating the costs of resources
needed to complete project activities, while cost budgeting is allocating the cost
estimates to individual project components so they can be measured or
managed. As the project manager, you have to have your resources planned and
costs assessed before you can build an honest budget. 69
 What an Estimate is NOT
• An estimate is not just effort in hours; it is all things related to the cost of the
project; you need to estimate all the cost items. Stress the importance of
documentation. If the estimate is not documented, it only resides in the
estimator's head.
• Documentation should contain the assumptions made when the estimate was
developed. Note that estimating is not pricing. An estimate is not a price but a
cost factor.
• Difference between cost and price:
• Cost is internal, for example, in manufacturing or development, cost is for
producing one unit.
• Price is what the client/project sponsor is charged.
• Ask students what they would say if someone said, “lower your estimates
because the price is too high.” To lower the price, either you can reduce the
scope (which will lower the estimates) or the marketing representative can
reduce the profit margin.
• The only perfect estimate is the one done after the work is complete.
70
 Items to Include in an Estimate
 An estimate should include all of the following items:
 The scope of the work that is included in the estimate
 The assumptions that were used
 Resources, such as staff, facilities, and material; consider the duration
 How quickly can the task be done with the skills available?
 What skill level is required to do the job?
 Project management should be included
 Expenses, both direct and indirect
 Risk and the cost of managing it to acceptable levels
 Documentation, which is critically important
 If an estimate is not documented, it only exists within the head of one
person
 The written estimate must contain the assumptions made when the
estimate was developed
71
 Items to Include in an Estimate
• Estimating involves determining the resources needed for the project as well as
costs/expenses and tasks/deliverables.
• A resource is any necessary item that may be used and charged to the project. It
includes human resources, facilities, and material. Brainstorm with the class about
potential resources. Remember that all resources have an associated cost.
• Many assume that estimates are just done for resources and cost purposes. But
estimating must account for other factors as well, such as effort and duration.
• Duration affects the estimates in terms of how quickly and in what sequence
tasks are to be done--whether they are contiguous or interruptible. Other tasks
can be interruptible and can have breaks as needed.
• Is a task dependent on a fixed completion time regardless of the number of
resources applied, or is it effort-based so that, with additional effort, it can be
completed much faster? Make sure you know what information you need to
determine effort and duration.
• Define expenses—a charge incurred when a bill or invoice is processed or work
time is reported against the project's authorized job codes.
72
 Items to Include in an Estimate
• Direct expenses are generally expressed in terms of direct costs (the labor,
materials, equipment, services, and fees chargeable to the project that must be
traceable) and indirect costs (costs not directly associated with a single final cost
objective, such as overhead and general and administrative expenses). These also
must be estimated.
• Examples of direct expenses are money expenditures, whether to be invoiced by
an external supplier or to be cross-charged by another department; personnel
(making, supporting, reviewing, or managing); consumable resources, such as
supplies and machine time; equipment and office facilities; travel and
accommodation expenses; overtime; office space; training costs; filing space; fax;
and publications.

73
 What To Do If Asked To Lower An Estimate
If you are asked to lower your estimate because the price is too high, what are
your options?
To lower the price, you can
 Reduce the scope
 Reduce risk and associated contingency
 Possibly reduce resource at the expense of schedule
 Management can decide to lower the profit margin

The degree of accuracy of an estimate depends on what phase of the development

cycle you are in; in the concept phase, the estimate has a lower degree of accuracy
than in the
Reasons forplanning
Estimatingphase

Estimating enables project managers to:

• Determine and evaluate the estimated costs of a project before authorizing
implementation
• Have a basis for tracking and managing project expenditures using activity-
based costing or other methods 74
 Reasons for Estimating
Estimating enables project managers to:
• Establish managerial baselines against which to measure expenditures during
the execution of the project
• Have a tool for evaluating routine project decisions
• Establish resources required and the resulting schedule
• Provide fact-based information to support investment analysis
• Provide a basis for tracking progress
• Estimating is used for evaluating, tracking, establishing baselines, providing
investment analysis data, and for determining resources and schedules.
• Review the bulleted items in the visual with the students. Ask them to expand
these reasons.

Many cost and schedule overruns can be traced back to a poorly

developed estimate, but even when the overrun is the result of poor
execution, a good estimate should have included allowances for this 75
 Reasons for Estimating
Estimating enables project managers to:
• Every cost and schedule overrun can be traced back to a failure of estimation.
Even when an overrun is due to poor project execution, we could say that the
estimation did not consider the possibility of poor execution.
• Many say they feel they must do projects for practically nothing to get support
for projects. They commit to doing the job with insufficient resources.
• Then, the project is authorized, and they must spend time scrambling for
resources. This points to the importance of estimating, and managers at all
levels must recognize its usefulness and support the process. Note the need to
have a baseline for measurement.

76
 When to Estimate
Estimating is not a one-time effort; it is done many times throughout the project
life cycle and it is a time-consuming process - There are different points in a project
when an estimate should be prepared, reviewed, or revised:
• Create the estimate when building the project organizational work plans for the
project
• Update the estimate when finalizing the project plan with updated work plans
• When determining whether to bid on an opportunity
• When taking over a project to validate proposal estimates
• When moving to the next phase of a project
• When an assumption proves to be invalid
• When the WBS changes to ascertain the effort and cost associated with the
change
• When there are authorized changes in resources, materials, or services
• Do remember to document assumptions in your estimates.

You must develop the WBS before preparing an estimate, even if it is only the
77
preliminary version
 Approaches to Estimating
Approach Commentary

We did it before Undoubtedly the most reliable information - provided you have previously undertaken a similar
project. Estimates are based on the actual results from a similar previous project. (Make sure
you use the actual results and not the original plan.) In some situations it is common to repeat
projects, e.g. roll-out programs, or working for software vendors who routinely implement the
solution for their clients.
Guess (estimation Well, an educated guess based on past experience of the Project Manager, and, hopefully, also
by analogy) based on the collective experience and knowledge of several Project Managers drawn from the
results of may specific projects. Here you are looking for analogous experiences from which you
can make direct estimates, or from which you can extrapolate an estimate bearing in mind what
specific differences there are in your proposed project.

Structured This uses the concept of estimation by analogy but builds a structured knowledgebase that is used
knowledgebase of to accumulate experience from many projects and Project Managers. The key to its success is an
past experience intelligent way of classifying and quantifying the many variables that affect the time and effort.

How many lines of This is an IT Project Manager's view of the world. Depending on the programming techniques
code and languages to be used, you can use average productivity rates to calculate how much effort
will be required. There are two significant flaws in this approach:
How did you estimate the number of lines of code that is the input to the calculation?
Delivering a business solution is a much wider challenge than creating a working computer
system. It is not valid to extrapolate the other work from the IT development effort. Some
systems are easy to build but relatively hard to implement (particularly, for example, package or
component-based solutions) and some solutions are complex in development terms but not
difficult to introduce into the business. Beware of statements like "testing effort should be 25% of
development".
Take a look at Putman's SLIM (Software Lifecycle Management) for an example of this logic.
78
 Approaches to Estimating

Approach Commentary

How much Again, more of an IT perspective, but, this time, giving a more scientific way of identifying the input
functionality criteria – i.e., how much functionality needs to be delivered.
Functionality can be identified from the scope and initial high-level design of the solution. It can be
classified and quantified so that tables based on past experience can be used to convert a given set
of functionality into realistic estimates.
Take a look at Albrecht's Function Point Analysis method to see this at work.

Top Down A subsidiary technique. Once you have established a good overall estimate for the project, you sub-
divide it down through the layers of the work breakdown structure, for example, development will
be 50% of the total, testing will be 25% etc; then sub-divide development and testing into their
components etc.

Bottom Up Each individual piece of work is estimated on its own merit.

These are then summed together to find the estimated efforts for the various summary level
activities and overall project.
One disadvantage with this approach is the tendency for overall effort to grow in line with the
amount of detail put into the plan.

Top-down An overall estimate is calculated for the project.

meets bottom- Individual estimates are then calculated, or drawn from previous plans, to represent the relative
up weights of the tasks. The overall estimate is then apportioned across the various summary and
detailed level tasks using the bottom-up figures as weights.
79
 The Complexity Factor
• Many people believe there is a direct linear
relationship between the amount of things
you have to achieve and the time it will take
to do them - if I do twice as much it will take
twice as long. That is a dangerous mistake;
the front pages of business newspapers
often feature people who thought like that.
• Here is something about "things" to think
about. We're not going to say what
the things are.
• If you have one thing - that is it; there
is just the one thing to deal with.
• If you have two things, then you have
the two things plus you have the way
they interact, interfere, overlap, and
deal with each other - that is three aspects to deal with.
• If you have three things, you have those three things, you have three
different sets of interaction between pairs of the three things, and you have
the way all three things combine - that is seven aspects.
80
 The Complexity Factor
• Four things is 15 aspects.
• And nine things is 511.
• Granted, effort and duration are also not proportional to the number of aspects
in a problem either - but you could argue that:
Doing something 10 times as big is 1000 times more complex!
...or 1023 to be exact - the formula is:

Areas generated = 2n-1 where n is the number of "things".

• So, what are these things we have been discussing? Maybe:

• number of systems to be replaced,
• number of integrated components,
• number of business processes to be re-engineered,
• number of departments involved,
• number of locations,
• number of people in a discussion.

81
 The Complexity Factor
Take an easy example: put students in a sub-group to work on a study question.

• One person alone would take a long time to do all the work.

• Two people are faster and produce a better result - but they are not twice as fast
as there is a lot of interaction between them.

• Three people are even faster and produce even better results - but, had it been a
work assignment, was there enough time saved and sufficient added value to pay
for the third person?

• Four people are usually - slower. Adding the extra person has increased the
amount of discussion and contention to the extent that the group takes longer than
the three-person group.

• Add more people and, clearly, they get even slower. Interestingly, with around six
people or more you will usually observe them split into sub-groups - instinct or
learnt behavior?
82
Estimating Process

Estimating Formulas
Cost = (Effort/Productivity) x Unit Cost
Duration =
(Effort/Productivity)/Availability

83
 Estimating Process
• Establish the estimating objectives: why is the estimate being prepared? What is
the required accuracy? Who is the intended audience? When are the estimates
needed?
• Determine project details—identify required information to prepare estimates.
Understand client/project sponsor's environment—might have major impact on
estimates—both technical and political factors can affect estimates. Recognize what
is unique about specific project.
• Select the appropriate model. For high-level tasks, proposal phase, or work to be
done months or years from now, consider a top-down model. For a detailed,
accurate estimate, consider a bottom-up, task-by-task approach.
• Develop the estimating strategy and plan (identify estimators, develop a plan to
gather the estimates, determine the type of estimating validation to be used, and
review the history of similar projects).
• Prepare the estimate—for top down, use a selected model. For a task-by-task,
bottom-up approach, generate detailed estimates in an iterative manner; estimate
your project management effort (typically 10–20% of total project's technical
effort); determine your project team size and duration, using square root rule for
initial cut. 84
 Estimating Process
• Do remember to have a risk plan completed. Any mitigation activities that have
costs associated with them must be included in the estimate.
• Determine how you'll validate the estimate (independent validator; detailed
scrutiny of every aspect of planning and estimating work; comparison or checking
with similar projects; sampling scrutiny in selected areas of most risk or
uncertainty). It is important to get an estimate that is possible and is not just
another number. Get someone outside to validate that your method is correct and
your assumptions are complete and valid.
• After completing the estimate and validating it, baseline it. Refer to the discussion
about baselining requirements. Baselining also is appropriate for an estimate. By
baselining, the project manager creates a recorded estimate and can use it as a way
to judge how useful the estimate was in planning.
• Use the estimate to develop a proposal or plan. Estimating is not just coming up
with a number. Estimates affect schedule, cost, and profit as well as client/project
sponsor satisfaction. Omitting an estimate can be very costly in the long run.

85
 Essential Estimating Terms (1 of 2)
Effort The number of labor units required to complete a task; it is usually
measured in staff hours or person hours
Level of effort This describes the activities that are necessary to support a project that
(LOE) cannot be scheduled; these activities, which are characterized by a
uniform rate of activity, are difficult to measure in terms of discrete
accomplishments but are usually measured in staff hours for the duration
of the activity

Duration This is the number of work periods, excluding holidays or other

nonworking periods, required to complete an activity or other project
element; duration is usually expressed in work days or work weeks and
there are two types of duration:
Contiguous duration is work time that is not interrupted
Interruptible duration is work time that might be interrupted

Effort-based The task has a total amount of effort that must be completed in order to
finish the task (This might also be referred to as staff effort and is usually
expressed in person hours)

Duration- The duration is constant regardless of how many resources are

based assigned to the task
86
 Essential Estimating
Resources include:
• Money expenditures, whether to be invoiced by an external supplier or to be
cross-charged by another department
• Personnel, whether to make, support, review, or manage
• Consumable resources
• Equipment and office facilities
• Travel and accommodation expenses

An example of productivity is:

• Two persons are to modify and convert 60 charts. Person A finishes 20 in 8
hours; person B finishes 20 in 6 hours. To finish 60 charts, person A requires 24
hours/3 working days; person B only needs 18 hours/2.6 working days.
• Activity duration is usually expressed in working days.

87
 Essential Estimating
An example of calendar time (elapsed time) is:
• 24 staff hours are required to convert a set of Freelance charts. If a person's
working time is 6 hours per day, the task requires 4 days to finish. If a person
starts Thursday, then 4 days become 6 days because 2 days are added for the
weekend (non-working time).

Define expenses.
• Direct expenses are generally expressed in terms of direct costs and must be
traceable.
• Examples of direct expenses are money expenditures; consumable resources,
such as supplies and machine time; equipment and office facilities; travel and
accommodation expenses; overtime; office space; training costs; filing space;
fax; and publications.
• Indirect costs are costs not directly associated with a single final cost objective.
These also must be estimated.
88
 Essential Estimating Terms (2 of 2)
Availability Is the time a staff person is available and willing to work (this is usually
measured in work hours per day or working days)

Productivity Is a relative measure of work in a time unit; different skill levels have different
productivity rates and you must determine which productivity should be used
for the estimate (the safest approach is to use an average productivity of
80%)

Utilization Is the amount of time a full-time equivalent (FTE) can be used on a project; an
FTE is not necessarily a specific individual but can be the combining of two or
more individuals whose efforts equal one work day or a portion of a work day

Utilization Describes the amount of time a full-time equivalent (FTE) can be used for the
factor length of the project

Working time Is the actual amount of time available for work. Usually measured in working
hours/day, working hours/week, working hours/month (working time takes into
account the working hours or time available for project team members)

Elapsed time Is the total number of days over which the task occurs (this is also called
calendar time, and is usually expressed in calendar days, weeks, or months)

89
 Validating an Estimate
To validate an estimate:
• Review the definition of the project
• Use same information and assumptions as original estimate
• Focus on sources of data
• Compare standards from a similar project
• Review the estimating method to see whether it is appropriate
• Determine whether the estimate meets the objective
• Use different approaches to validate the estimate
• Ensure that all mitigation tasks are included in the estimate
• Pay extra attention to Big Ticket items

Validate all estimates before you consider them to be complete

90
 Rules of Estimating
When you estimate a project:
 Employ the most appropriate approach and the most accurate method
 Communicate the level of accuracy
 Involve the project team that are on board in the estimating process so that they
can provide insight and can become vested in the process
 Use history as a base for estimates
 Apply standards when they are available
 Do not work to justify a predetermined result
 Do not undervalue estimates
 Recognize that estimating takes time
 Document the assumptions the estimate is based upon (This is a mandatory
step in the process)

The rules of estimating focus on honesty; each rule is crucial to successful estimating
91
 Rules of Estimating
The rules of estimating focus on honesty. If you want an honest estimate, each
element of this list has to be honest. The rules of estimating are:
• Use the most appropriate approach and the most accurate method. When
building an estimate, even if it is high-level, you must follow the rules. Each rule is
crucial to successful estimating.
• Communicate the level of accuracy. The level of precision refers to the level of
accuracy and trust that a project manager puts in an estimate (for example, if it is a
broad estimate, don't claim total accuracy).
• Involve the project team that are on board in the estimating process so that they
can provide insight and can become vested in the process.
• Base estimates on history. Determine whether the team members have a history
of developing poor estimates. If the software estimators are usually correct, then
their estimates should have greater credence.
• Use standards, if available.

92
 Rules of Estimating
The rules of estimating are:
• When developing estimates, avoid starting with a presumed result and then
working backward to justify this result. Making estimates fit the available dollars
does not generate an honest estimate. If your estimates are not aligned with the
targeted cost or schedule, address the problem and resolve it through trade-offs of
scope, schedule, and cost.
• Do not undervalue estimates. Undervalued estimates that might win business
usually result in cost overruns that might be invisible at the time of contracting. As
the project manager, you will be held accountable for that overrun.
• Recognize that estimating takes time. On average, it can take up to 2% of the total
technical time to determine an estimate.
• Document your assumptions. This is a mandatory step in the process. An estimate
is not an estimate unless it is written down, including both assumptions and
approach, in addition to numerical values.
Remember that these rules are fundamental to estimating. You must follow them
if you want to develop a valid estimate.
93
 Drivers of effort
There are many other factors that will influence the effort it takes to deliver a
successful business solution. Let's finish up with an inventory:
People Process Technology
Strength of sponsorship Number and complexity of processes Functionality of IT system
Availability of good resources for the to be re-engineered Complexity of the technology to be used
project team Extent to which processes are
Development techniques and languages
Organizational resistance to change intertwined
to be used
Extent to which the process is within
Organizational complexity Use of packaged software or component
the control of the Project Sponsor (e.g.
Organizational culture based technology
dependence on action from external
supplier) Amount and complexity of integration
Morale
and interfacing with legacy systems
Local cultures Degree of improvement required
(e.g.10% faster is easy; 90% faster will Familiarity of development staff with the
Ease of communication be more of a challenge) technology to be used
Number of locations involved Quality of support for these processes Productivity of development staff
Number of departments to be from commercially available software Desired quality of solution
restructured products
Acceptable risk levels – e.g. depth of
Number of staff affected Availability of best practice knowledge testing required
concerning the processes within this
Amount of re-training required industry Level of documentation required
Impact on external people or bodies
(e.g. customers, suppliers, regulators)

94
 Cost Estimating and Cost Budgeting
• One reason for creating a project budget estimate is to provide a basis for
tracking and managing project costs; specific tasks within the estimating process
are cost estimating and cost budgeting.
• Cost estimating - consists of determining the cost of all of the elements
needed to complete the project.
• Cost budgeting - is the allocation of the determined cost estimates to
individual project components so that those costs can be measured and
managed as the project is executed.
• When approved, the budget is placed under change control and is the basis for
establishing the financial measurement baseline of the project.
• As stated earlier, estimating is determining the resources (labor, equipment, and
facilities) needed to complete the project.
• One reason for creating a project budget estimate is to provide a basis for
tracking and managing project costs.
• Specific tasks within the estimating process are cost estimating and cost
budgeting.
95
 Cost Estimating and Cost Budgeting
• When approved, the budget is placed under change control and is the basis for
establishing the financial measurement baseline of the project.
• Cost estimating consists of determining the cost of all of the elements needed to
complete the project.
• Cost budgeting is the allocation of the determined cost estimates to individual
project components so that those costs can be measured and managed as the
project is executed.

96
 Resourcing - Why, What, How?
• Resourcing means assigning actual resources (a rather cold expression which
normally means people) to the project.
• There are two very different aspects to this:
• Deciding which resources to apply to which work items in the project plan,
and
• Actually getting the resources to work for the project.

Resourcing Planning & Scheduling

• The allocation of resources to the project plan is part
of the overall process of planning, estimating and
resourcing the project. Each time the plan is reviewed
and revised, resourcing will be addressed.
• The initial planning will have identified the work to be done. Estimates will
have been formed, not just for the overall effort but normally showing
effort per resource type.
• Initially, the Project Manager will have identified resource requirements
theoretically. 97
 Resource Planning and Scheduling
For example, you may have decided that project tracking requires:
• 10 days effort from a Project Office Manager,
• 20 days from a Project Administrator, and
• 5 days from the Project Manager.
Now you need to consider the real world.
• Do you have people like that?
• If not, would you be able to get them?
• What is their availability / when can you get them?
• What else will the Project Administrator and Project Office Manager be
doing - is there enough work altogether to justify two people - or could
one person handle both roles?
• Is it practical to use a resource part time on the project?
• Who is able to agree and authorize the use of the resources?
• How do we get them to concur - particularly if it is a loss for their own
98
area?
 Resource Planning and Scheduling
• Very often these "real world" conclusions will have an impact on the original
plans and estimates. Maybe you could not get the number of people you
wanted. Maybe a key resource will not be available until later. Maybe you need
to re-sequence tasks to avoid overloading a unique resource.
• As the plan is refined, the Project Manager incorporates these practical
considerations and repeats the scheduling process until an optimum achievable
plan has been generated.
Mobilizing Resources
• Getting the resources for a project requires very different Project Management
skills. Just because you put something in the plan and get it agreed does not
mean that it will happen.
• It usually takes strong support from the Project Sponsor and constant attention
from the Project Manager to make sure the participants are released to work
on the project as agreed.
• These resources usually have enough work to keep them busy full time in their
normal line departments. You have to convince them and their managers that it
really is essential to make them available - even though it causes pain in their
99
own departments.
 Mobilizing Resources
• Getting the right level of input is particularly difficult where resources are only
planned to be working part time on the project. Try to get them physically away
from their line job and working from the project team's own accommodation
otherwise they will constantly be diverted back to their regular job.
• Here is an example from a real project that shows the potential difficulty
and impact of resource mobilization.

100
 Mobilizing Resources
• These charts were produced to show the Project Sponsor that the promised
input from the business was not materializing Only the external
consultants were matching our expectations.
• It was thought to be a strong message, but the response was - "it shows you
can get resources if you pay high fees for them". Nevertheless, suggested point
was taken.

Resourcing at the Start of the Project

• During the Project Definition and initial planning of the project, resourcing is
generally considered at a summary level.
• You will need to identify roles or classes of resource and their general
capability, availability and costs etc.
• This is also the time to start the campaign to persuade line management that
they need to participate and release resources for the project.
• You might start by building a matrix of the resources you need - one dimension
showing the type of capability, knowledge or skill they provide and another
dimension showing the level of their authority and/or ability.
101
 Resourcing at the start of the project
• To deliver a business solution you will need to include all the participants
required for the complete solution including those from the business and
external resources.
• For the initial high-level project plan you will not necessarily identify
individual resources - unless those individuals play a significant individual
role.
• For example,
• you need to say that the Finance Director has to participate in
formulating the vision for transforming the finance function within the
organization - and you need to check availability, commitment, etc, but
you do not need to name the third programmer in the MIS reporting
team.
• It is enough that you can identify the types of resource, the general
availability of that resource type and the approximate cost.
• Based on this information, the initial plan, timing, costs and benefit model
can be reviewed and, if necessary, revised.
102
 Resourcing at the start of the project
• Bear in mind, however, that obtaining the desired individual resources can take
time, so move on as quickly as possible to the identification of individual
resources - particularly those required for the initial phase of work.

Resourcing needs will vary throughout the project.

1. Typically, the early stages require intensive participation from the organization's
leadership and management normally supported by specialists in the industry, the
processes, the technology, Human Resources and organizational change. These
tend to be senior people.
2. For the detailed design, the balance will shift towards more analysts and
designers working alongside the "architects" from the earlier work.
3. As the solution is constructed, typically you will require a much larger number of
more junior staff to do the actual work.
4. When the solution is ready for testing, you will again require participation from
the organization's management plus a significant number of users.
103
 Detailed Resourcing per Phase
• By this stage all individuals should be identified - assigning actual names to the
roles identified earlier. As part of that process, practical considerations and
rationalization may mean you need to fine-tune the plan and estimates.
• Now that you have a detailed view of the project's participants, you should also
consider how best to organize them into teams and sub-teams.
• It often takes time to get the identified resources from their current work duties
into the project team.
• You will need to make plans sufficiently in advance that the resources can
hand over their current duties and be released for the team.
• Before making any decisions or assumptions about resourcing, you will
need to have agreed the details with the relevant line management.
• Use the Project Sponsor to apply pressure where necessary.
• As you determine the detailed plan, typically prior to the start of each phase,
you will need to consider the resourcing in detail such that individual resources
can be assigned to specific tasks.
• As well as getting the people onto the team, remember to ensure they have104
the
accommodation and infrastructure they will need.
 Detailed Resourcing per Phase
• Typically, team members may need to have:
• Car parking,
• Security clearance and physical access to the work areas,
• Desk,
• Telephone,
• PC with network connection,
• Accounts on relevant computer systems (e.g. the target technology, the
project's documentation and knowledge repositories, the Email system, the
organization's Intranet, the external Internet, external hubs / storefronts etc),
• Access to office facilities such as photocopiers, stationery, etc
• Somewhere to eat, get coffee, go to the toilet etc.
• If they are working away from home, you may also have to deal with their
accommodation and travel arrangements. They may also require initial training in
the technology or coaching on the project's working methods.
• In general, it is good practice to devote some time to welcoming team members
105
and coaching them about the project.
 Managing Resources during the Project

• During the course of the project, it is unlikely that you will make any major
changes in the resourcing.
• Of course, circumstances may change - plans may need review, progress
may slip, people may resign, individuals may perform poorly etc.
• In these cases the resourcing issues may need re-examination.

Resourcing Issues at Phase End

• At each phase end there are two choices for each resource, either:
• They stay on the project for the next phase, or
• They need to return from the team.
• Ideally, this choice should be clear well in advance so they have sufficient
warning and details can be agreed.
• Detailed planning and resourcing for the following phase should be
performed well in advance. Where team members will be leaving, their
next role or assignment should be identified.
106
 Resourcing Issues at the End of the Project
At the end of the project there are two choices for each team member, either:
• become part of the continuing benefit realization team, providing such things as
coaching, support, maintenance, enhancements, and upgrades, or leave the
team.
A good Project Manager cares about the well being of the project team.
• Where possible, you should ensure your team members have a clear, valuable role
to return to.
• Their capabilities and experience should be rewarded and exploited in their line
positions. Very often, former team members make excellent coaches, team
leaders, and managers back in their line roles since they return with an excellent
understanding of the new business solution.
• If the team member is returning to a pool of resources, e.g. an analyst/
programmer in the organization's IT department, make sure the resource
managers for that pool know the details in advance so they can re-allocate the
resource in a valuable way.
• The Project Manager will often have a formal duty to assess or appraise the
performance of project staff. Even where there is no formal process, it is 107
appropriate to provide useful feedback to the participant.
 Resourcing Process
Here is a summary of the overall process...

108
 Quality
 Quality is not an absolute requirement
 It is wrong to assume that maximum quality is desirable.
 Should every car be built to the same quality as a Rolls Royce?
 Should every computer system be held back until there is not one single flaw
remaining?
 Required quality should be considered as part of the overall Project Definition
work.
 It will impact upon such things as the estimates and benefit case.
 Such things are business decisions.
 They can only be taken by the Project Sponsor and senior management team of
the organization.
 By Quality Management, we mean all the activities that are intended to bring
about the desired level of quality.
 By Quality Audit we mean the procedural controls that ensure participants are
adequately following the required procedures. 109
 Quality

 These concepts are related, but should not be confused. In particular, Quality Audit
relates to the approach to quality that is laid down in quality standards such as the
ISO-900x standards.
 The abbreviation "QA" has been generally avoided in the e-PM book as it can mean
different things - e.g. "Quality Assurance", "Quality Audit", testing, external
reviews, etc.
 Quality decisions are not just a matter of the reliability of the end product - they
can also affect the scope and project approach.
 This is particularly an issue with e-solutions:
 Do you want something magnificent, or do you want something fast before your
competitors get ahead?
 Do you want a complete solution, or will you settle for a partial solution and come
back to finish it at a later date?

110
 Quality is not an absolute requirement

 Very often, commercial pressures mean that the best business decision is to
achieve an "80%" solution fast.
 Many early e-commerce business-to-consumer solutions looked great to the
customer but involved staff re-keying data into the sales order systems or manually
processing credit card transactions.

You need to make it clear that these are mutually

exclusive alternatives - you cannot together do
magnificent, complete and fast.

Case Study
A company decided to achieve a rapid deployment by
focusing on 80% solutions and breaking their requirements
into five phases of development and deployment.
A project reviewer asked if they had considered how
functional the end result would be. Would it be 80% x 80%
x 80% x 80% x 80%? That would be 33% - one third what
you need. 111
 Quality & Project Quality Management

 Quality - Is the degree to which a set of inherent characteristics fulfills requirements

 Quality is the totality of features and characteristics of a product or service that bear
on its ability to satisfy stated or implied needs
 Stated and implied needs are the inputs to developing project requirements
– A critical element of quality management in the context of a project is to turn the needs,
wants, and expectations of stakeholders into requirements by performing a stakeholders
analysis, performed as part of project scope management
 Project Quality Management processes include all the activities of the performing
organization that determine quality policies, objectives, and responsibilities so that the
project satisfies the needs for which it was undertaken
 It implements the quality management system through the policy, procedures, and
processes of quality planning, quality assurance, quality control, with continuous
process improvement activities conducted throughout, as appropriate

112
 Quality & Project Quality Management

Some goals of quality programs include:

- Fitness for use. (Is the product or service capable of being used?)
- Fitness for purpose. (Does the product or service meet its intended purpose?)
- Customer satisfaction. (Does the product or service meet the customer's
expectations?)
- Conformance to the requirements. (Does the product or service conform to the
Requirements?)

Quality becomes achievable when:

 A project quality management system that includes processes such as quality
planning, quality assurance, and quality control is established
 Both the management of the project and the product of the project are addressed
 Customers' requirements are carefully managed and reviewed to meet customer
satisfaction and the project schedule
 Project reviews are conducted
113
 Project Quality Management Processes
 Quality Planning - Is the process of identifying which quality standards are
relevant to the project and determining how to satisfy them.
 Quality Planning is one of the key processes during the development of the
project management plan and should be performed in parallel with the other
project planning processes.
 Perform Quality Assurance (QA) - Is the process of applying the planned,
systematic quality activities to ensure that the project employs all processes
needed to meet requirements.
 Quality Assurance provides an umbrella for another important quality activity,
continuous process improvement.
 Perform Quality Control (QC) - Is the process of monitoring specific project
results to determine whether they comply with relevant quality standards and
identifying ways to eliminate causes of unsatisfactory performance.
 Quality Control should be performed throughout the project with quality
standards which include project processes and product goals.

114
 Aspects of Quality Management
Aspect Summary

Quality Plan Define and agree the needs for quality and the specific
approaches to meet them.

Phase Quality For each phase, what specific things will be done and what
Requirements specific deliverables will be produced.

Apply Quality Throughout the work, the defined approach to quality will be
Methods followed. Work or deliverables falling short of the standards will
need to be re-worked to achieve an acceptable standard.

Phase Quality Before each phase can be closed, a review is performed to

Review ensure that acceptable quality standards have been achieved.

Project Quality Before the project can be completed, the overall conformance to
Review Quality Methods and requirements should be assessed and
approved.

115
 Quality - Why, What, How?
Responsibilities for Quality
• The Project Manager will, of course, have overall responsibility for the quality of
the project.
• It is equally true that all participants have a role to play in delivering good results.
Developing a quality culture amongst the team will normally generate greater value
and satisfaction.
• Encourage the belief that the right level of quality is more important than getting
things done fast.
• If there is a choice to be made between quality and progress it should be a matter
for the Steering Committee to decide.
• Other managers will also be involved in the Quality Management process.
• In larger projects there may be a Quality Manager and Quality Team.
• Team Leaders and other senior staff will also be involved in the processes.
• In some environments, certain Quality Management functions may be performed
by independent reviewers from outside the Project Team.
116
• Responsibilities for quality should be agreed and communicated to all participants.
 Quality Management Plan
• Quality Management Plan - Describes how the project management team
implements the performing organization's quality policy
• Provides input to the overall project management plan and must address quality
control (QC), quality assurance (QA), and continuous process improvement for
the project
• Should include efforts at the front end of the project to ensure that the earlier
decisions are correct.
Preparing for Quality Management at the Start of each Phase
• One basic approach is to create two lists:
 All the work that should be done (including the methods, techniques and
procedures to be used)
 All the deliverables that should be produced (including the formats and
standards that should be applied)
• This provides a guide for the people conducting the work and a checklist for the
phase-end review.
• It is good project management practice, as well as a Quality Management
process, to identify in advance all the anticipated deliverables. 117
 Inside Quality Management Plan
Here are some types of thing you should consider.
Type of content Description Examples
Objectives What are the objectives of Acceptable levels of functionality to achieve
Quality Management? To what Acceptable levels of security, bugs etc
extent is quality a requirement in Investment in testing
preference to timescales, costs,
functionality etc?

Requirements What specific requirements are to Review and sign-off of specific deliverables or
be addressed work by specified people types and depth of
testing required
Availability of specified functions

Quality Methods What approaches and methods Iterative development in specified stages
Methodology to be followed Peer review of all
deliverables

Standards What format and detail should web page layout & navigation standards coding
deliverables be in standards documentation standards
Procedures Specified procedures for project check-in and check-out of code documentation
tasks control procedure issues management
procedure

Quality Management Plan is often an evolving document. As the project progresses it will
need to adapt to changes and decisions. For example, detailed website design and navigation is
118
unlikely to be defined at the start of the project unless you are adding to an existing solution.
Preparing for Quality Management at the Start
of each Phase
• When the detailed plan for each phase is completed it will be possible to
identify the specific Quality Methods and controls that should be applied - and
what they should be applied to.
• For each one, you should identify:
 Nature, description and purpose of the deliverable,
 Quality standard (e.g. discussion draft, final quality, reviewed or tested for
external publication)
 Dependencies (what must be completed prior and what further deliverables
depend upon this one)
 Date required
 Author/creator
 People who have to review it
 People who have to approve it

119
Preparing for Quality Management at the Start
of each Phase
• For each one, you should identify:
 People who should receive it for information or use (but who do not get the
opportunity to review or approve)
 Other distribution (e.g. third parties, auditors, publishing, filing)
 Security/secrecy requirements - i.e. who can not see or use it
 Currency information (e.g. must be maintained, updateable, one-off,
temporary, final project deliverable)

120
 Bringing about Quality during the Work
 The best Quality Methods will depend on the type of project - the team,
application, language, technology, participants, environment, etc.
 They will also be affected by strategic decisions about the investment in
quality.
 Here are some examples:
 All requirements should be prototyped iteratively in collaboration with the
responsible user manager
 Designers are expected to consider any reasonable alternative
approaches and discuss them with the responsible user manager before
creating a detailed design
 Any anticipated impact on timescales, resourcing, deliverables, or benefits
should be communicated to the project manager as soon as possible and
before any revised action is taken
 All documents should include control information such as version
numbers, issue dates, status, authors, reviewers etc
 All designs should be reviewed by someone from a different sub-team
121
and by the overall solution architect
 Bringing about Quality during the Work

 Here are some examples:

 Any aspect of a deliverable which could impact upon another deliverable
should be noted in the issues management system.
 Only one person can have update access to a document or system
component at any one time - access will be controlled through the
configuration management and/or documentation control procedures.
 All completed work will be signed off by the responsible user manager.
 Once a deliverable is completed, signed off and closed it can only be re-
opened by following the change control procedure.
 Developers are not allowed to test their own work.
 Appropriate end users must be involved in all systems tests - each test
must be signed off by the responsible user manager.
 Where any correction is applied to a deliverable, all other deliverables
which could be affected must be re-examined and/or re-tested.

122
 Bringing about Quality during the Work

 Here are some examples:

 All components should be sized and tested for absolute peak usage
 Developers cannot access live components directly - they need to check
them out using the configuration management and/or documentation
control procedures.

 There will also be a number of rules, standards and procedures, e.g.:

 Format of documents
 Techniques to use (e.g. estimating technique, modeling technique)
 Language (s) to use
 Naming conventions
 Documentation standards
 Procedures to follow (e.g. documentation control, configuration
management, issues management, bug reports, testing). 123
 Rules, Standards and Procedures

 It will be easier to manage quality if the application of Quality Methods and

controls is tracked continuously through the project, rather than relying solely
on reviews at the end of each phase.
 The status of work and deliverables can be tracked against the lists prepared
for the Phase.
 The tracking information should show the stage of progress (e.g. not started, in
progress, completed, signed off), and the status of specific controls, reviews,
signatures etc.
 In particular, completion should be logged and a check made to ensure that
the correct methods, controls and approvals were completed.
 One final thing to note about these Quality Methods:
– They are all rules for people to follow.
– In fact, most people do not respond well to being given rules.
– The most significant thing the Project Manager and Team Leaders can do to
ensure appropriate quality is to take a personal interest in the quality of work
being done, providing coaching and feedback as appropriate. 124
 Reviewing Quality at the end of a Phase
 Before the phase can truly be considered to be complete, you should review
that you have:
 Done everything you said you would do in the way you said you would do it,
 Produced everything you said you would produce to an acceptable standard.
 There will, of course, be deviations. In each case it should be clear whether:
 The change was agreed and its impact has been dealt with
 The shortcoming was not desirable but is acceptable in terms of delivering the
overall benefit from the project
 The failure will be remedied at a later (defined) stage
 The fault must be remedied now before the phase can be completed.
 The phase-end Quality Review should be agreed and signed off by the
Project Sponsor and/or senior leadership representing the organization.
 The Quality Methods you have applied throughout the phase should have
ensured that there is no surprise at the end of the phase.
There should be little to do at the end of the phase - if there are significant problems
it is too late to do anything without an adverse impact on costs and timescales. 125
 Reviewing Quality at the end of the Project

 The senior leadership will consider the extent to which the project has
adequately completed the planned work and deliverables (subject to agreed
changes during its course).
 As well as the Quality Management aspect of such a review, there will also be
many other reasons to examine the success of the project, for example,

• Learning lessons,
• Planning further improvements,
• Improving estimating techniques,
• Paying contractors and suppliers etc.

126
 Goals of Quality Assurance
 Project managers and the quality assurance group work together to ensure
adherence to the defined management processes and procedures
 Results of quality assurance reviews should be shared and discussed with
project managers and teams, and reviewed periodically with senior project
management
 The project manager and QA resource should jointly obtain decisions and
guidance from senior management on all unresolved noncompliance issues
 Leads to taking actions to increase the effectiveness and efficiency of the
project to provide added benefits to the project stakeholders (Quality
Improvement)
 Assurance may be provided to the:
– Project management team and to the management of the performing
organization (Internal Quality Assurance)
– Customer and others not actively involved in the work of the project
(External Quality Assurance)

127
 Continuous Improvement
 Continuous Improvement (CI) - Adopting new activities and eliminating those
which are found to add little or no value
 The goal is to increase effectiveness by reducing inefficiencies, frustrations,
and waste (rework, time, effort, material, and so forth)
 The Japanese term is Kaizen, which is taken from the words Kai meaning
change and zen meaning good
 The Plan- Do-Check-Act cycle of activities is designed to drive continuous
improvement and is the basis for quality improvement
 The concept is simple to teach and understand:
 Plan: Plan the work,
 Do: Carry out the plan,
 Check: Check on the result, and
 Act: Then take action to improve performance
 Repeat the cycle to improve continuously
This cycle is linked by results with the results of one part of the cycle becoming
128
the input to another part of the cycle
 Continuous Improvement

 This cycle is linked by results with the results of one part of the cycle becoming
the input to another part of the cycle.
 Plan-Do-Check-Act (2) - The concept is simple to teach and understand: Plan
the work, carry out the plan, check on the result and then take action to
improve performance. Repeat the cycle to improve continuously. The PDCA
cycle is now included in the ISO standards.
 It's described in the context of business process management as follows:
• Plan - Establish the objectives and processes necessary to deliver results in
accordance with customer requirements and the organization policies.
• Do - Implement the processes.
• Check - Monitor and measure processes and product against policies,
objectives, and requirements, and report the results.
• Act - Take action to continually improve process performance.

129
 Continuous Improvement

 Plan-Do-Check-Act - A Problem Solving Process (3)

– PLAN: Step 1: Identify The Problem; Step 2: Analyze The Problem;
– DO: Step 3: Develop Solutions; Step 4: Implement a Solution
– CHECK: Step 5: Evaluate The Results, Achieved the Desired Goal?
– ACT: Step 6: Standardize The Solution and Capitalize on New Opportunities
 Additional Information — The concept of the Plan-Do-Check-Act (PDCA) Cycle
was originally developed by Walter Shewhart, the pioneering statistician who
developed statistical process control in the Bell Laboratories in the US during the
1930's, to drive
 Continuous improvement - Though initially implemented in manufacturing, it
has broad applicability in business. It was taken up and popularized from the
1950s on by W. Edwards Deming, the famous Quality Management authority.
 It is also known as the Shewhart cycle and Deming cycle.

130
 Quality Control (Assurance) Overview

 Quality control is performed throughout all phases of the project life cycle
 Quality control is usually conducted by a quality control department or by
other kinds of control groups that have been given the responsibilities
 Results include both product results, such as deliverables, and management
results, such as cost and schedule performance
 Project management teams should have a working knowledge of statistical
quality control, especially sampling and probability, to help them evaluate
quality control outputs

131
 Goals of Quality Control

 Quality improvement
 Rework actions to bring defective or nonconforming items into compliance
with requirements or specifications
 Completed checklists which become part of the project's records
 Process adjustments, which involve immediate corrective or preventive action
as a result of quality control measurements

132
 Cost of Quality
 Cost of quality is the total cost of all efforts to achieve product or service
quality which includes all work to ensure conformance to the requirements as
well as all work resulting from nonconformance to the requirements
 Prevention and appraisal costs (cost of conformance) include costs for
quality planning, quality control (QC), and quality assurance to ensure
compliance to requirements (that is, training, QC systems, etc..)
 Failure costs (cost of non-conformance) include costs to rework products,
components, or processes that are non-compliant, costs of warranty work,
waste, and loss of reputation
 Cost of a quality system is often viewed as a negative cost because errors in
work have been traditionally accepted as a cost of doing business
 In addition to the cost of conformance (listed below) and the cost of
nonconformance (also listed below), other costs of a quality program include:
- Prevention costs
- Approval costs
- Cost to build right the first time
- Training programs
- Statistical Process Control (SPC) Costs 133
 Cost of Quality
 Additional Information — Cost of Conformance:
• Planning
• Training and indoctrination
• Process control
• Field testing
• Product design validation
• Process validation
• Test and evaluation
• Inspection/Quality audits
• Maintenance and calibration
 Cost of Nonconformance:
• Scrap
• Rework
• Expediting
• Additional material or inventory
• Warranty repairs or service
• Complaint handling
• Liability judgments
• Product recalls 134
 Cost of Quality
 Cost of Non-Quality:
• Cost of non-quality is estimated to be 12-20% of sales.
• Waste of time and materials
• Rework of poor quality products and additional material for rework
• Delays in schedule
• Product and service image
• Corporate image
• Product corrective actions
 Major Cost Categories of Quality:
• Prevention Cost - The cost to plan and execute a project so that it is error-free.
• Appraisal Cost - The cost of evaluating the processes and the outputs of the
processes to ensure the product is error-free.
• Internal Failure Cost - The cost incurred to correct an identified defect before the
customer receives the product.
• External Failure Cost - The cost incurred due to errors detected by the customer.
This includes warranty cost, field service personnel training cost, complaint handling,
and future business losses.
• Measurement and Test Equipment - Capital cost of equipment used to perform
135
prevention and appraisal activities.
 Cost of Quality
 Opportunities for Reducing Cost:
• Just-in-Time - Concept of zero inventory in a manufacturing plant. Reduces cost
of storing and moving parts; cost of inventory; cost of parts damaged through
handling, etc.
• Product Life Cycle Cost - Concept of reducing overall product life cycle cost by
linking the cost areas of the product life cycle (R&D, acquisition, and operations
and maintenance) and considering each one's cost implications for the other.
• Product Maturity - Identifying, documenting, and correcting failures early helps
products achieve stability earlier in the life cycle (see Ireland, IV-9).
 Areas of Waste in Projects
- Waste in rejects of completed work
- Waste in design flaws
- Waste in work-in-process
- Waste in motion for manpower (under-trained employee)
- Waste in management (Improper direction of work)
- Waste in manpower (Misplaced or waiting workers)
- Waste in facilities (Ordering excess material)
- Waste in expenses (Unnecessary meetings, travel) 136
 Quality & People in Project Management
 Management defines type and amount of work
 The Employee can only assume responsibility for meeting the requirements of
completing the work when the employee:
 Knows what's expected to meet the specifications
 Knows how to perform the functions to meet the specifications
 Has adequate tools to perform the function
 Is able to measure the performance during the process
 Is able to adjust the process to match the desired outcome
 Project Quality Team consists of:
 Senior Management
 Project Manager
 Project Staff
 Customer
 Vendors, suppliers, and contractors
 Regulatory Agencies 137
 Quality & People in Project Management
 Project Manager has the ultimate responsibility for Quality Control and Quality
Assurance
 Customer sets the requirement for acceptable quality level
 Reviews and Audits:
 Management reviews determine the status, progress made, problems, and
solutions
 Peer reviews determine whether proposed or completed work meets the
requirements
 Competency center reviews are used to validate documentation, studies, and
proposed technical solutions to problems
 Fitness reviews and audits determine the fitness of a product or part of a
project (addresses specific issues)
 The collection of quantitative data for statistical analysis is the basis for proactive
management by FACT rather than by EXCEPTION
 Management by exception lets errors and defects happen before management
intervention 138
 Quality Audits help Ensure Quality

 A Quality audit is a structured, independent review to determine whether

project activities comply with the organizational and project policies, processes, and
procedures.
 Objective of a quality audit is to identify inefficient and ineffective policies,
processes, and procedures in use on the project
 The subsequent effort to correct these deficiencies should result in a reduced
cost of quality and an increase in the percentage of acceptance of the product or
service by the customer or sponsor within the performing organization
 Quality audits confirm the implementation of approved change requests,
corrective actions, defect repairs, and preventive action
– Additional Project reviews include:
 Estimate review
 Project plan review
 Ongoing project review
 Project completion review
 Special review
– Estimate review questions include:
• Were documented procedures used?
• Did an independent party also review the estimate?
139
 Quality Audits help Ensure Quality

– Project plan review questions include:

• Were documented procedures used?
• Were one or more QA project reviews conducted?
– Ongoing project review questions include:
• Is progress being made according to the project plan?
• Is there evidence of adherence to management processes and procedures?
– Project completion review questions include:
• Was completion of all project tasks verified?
• Are all problems and issues resolved?
– Special review questions include:
• Were any special reviews requested at any time during the development lifecycle?
• On what special circumstances did the reviews focus?

140
 Quality Audit Summary Example

Under control
CLASS A: Minor problems might exist, but the project manager has an
effective plan for resolution; no major existing potential problems
have been identified
Currently under control
CLASS B: Existing or potential problems must be resolved to avoid
deterioration
Significant problems
CLASS C: Corrective plans required immediately. Probably will exceed
estimates or budgets; aggressive management action essential to
regain control
Major problems
CLASS D: Definite financial impact, serious problems with client
acceptance, or negative impact on client's business.; thorough
management evaluation required; executive call on client

141
 Principle behind Quality Audit
 The principles of Quality Audit, in the sense we mean it here, are based on the
style of quality standards used in several formal national and international
standards such as the ISO-900x international quality standards. These standards do
not in themselves create quality.
 The logic is as follows:
Every organization should define comprehensive procedures by which their products
or services can be delivered consistently to the desired level of quality.
As was discussed in the section on Quality Management, maximum quality is rarely
the desired objective since it can cost too much and take too long.
The average product or service provides a sensible compromise between
quality and cost.
The principle is that each organization should create thorough, controlled procedures
for each of its processes.
Those procedures should deliver the quality that is sought.
 There is also a legitimate market for products that are low cost and low quality.
 Standards authorities do not seek to make that business judgment and enforce it
upon businesses, except where certain minimum standards must be met (e.g. all
cars must have seat belts that meet minimum safety standards, but there is no 142
attempt to define how elegant or comfortable they are).
 Principle behind Quality Audit
 The Quality Audit, therefore, only needs to ensure that procedures have been
defined, controlled, communicated and used.
 Processes will be put in place to deal with corrective actions when deviations
occur.
 This principle can be applied to continuous business process operations or
recurring project work.
 It would not be normal to establish a set of quality controlled procedures for a
one-off situation since the emphasis is consistency.
 This principle may be applied whether or not the organization seeks to establish
or maintain an externally recognized quality certification such as ISO-900x.
 To achieve a certification, the procedures will be subjected to internal and
external scrutiny.

143
 Preparing for Quality Audit
 Thorough procedures need to be defined, controlled, communicated and used.
Procedures should cover all aspects of work where conformity and
standards are required to achieve desired quality levels. For example, one
Thorough might decide to control formal program testing, but leave the preliminary
testing of a prototype to the programmer's discretion.

Any recurring aspect of work could merit regulation. The style and depth of
Procedures the description will vary according to needs and preferences, provided it is
sufficiently clear to be followed.
A major tenet is that the defined procedures are good and will lead to the
desired levels of quality. Considerable thought, consultation and trialing
Defined should be applied in order to define appropriate procedures. Procedures will
often also require defined forms or software tools.

As with any good quality management, the procedures should be properly

Controlled controlled in terms of accessibility, version control, update authorities etc.
All participants need to know about the defined procedures - which they
Communicated exist, where to find them, what they cover. Quality reviewers are likely to
check that team members understand about the procedures.
The defined procedures should be followed. Checks will be made to ensure
this is the case. A corrective action procedure will be applied to deal with
Used shortcomings. Typically the corrective action would either be to learn the
lesson for next time, or to re-work the item if it is sufficiently important.144
 Preparing for Quality Audit
 There is no reason why these Quality Audit techniques should conflict with the
project's Quality Management processes.
 Where project work is recurring, the aim should be for the Quality Methods and
other procedures to be defined once for both purposes.
 Problems may occur where the current project has significant differences from
earlier ones.
 Quality standards may have been set in stone as part of a quality certification.
 In extreme situations this can lead to complete inappropriate procedures being
forced upon the team, for example, using traditional structured analysis and design
in a waterfall style approach for what would be handled best using iterative
prototyping.
 The Project Manager may need to re-negotiate quality standards with the
organization’s Quality Manager.

145
 Operating Quality Audit
 A Quality Audit approach affects the entire work lifecycle:
 Pre-defined standards will impact the way the project is planned
 Quality requirements for specific work packages and deliverables will be
identified in advance
 Specific procedures will be followed at all stages
 Quality Methods must be defined and followed
 Completed work and deliverables should be reviewed for compliance.
 This should be seen as an underlying framework and set of rules to apply in the
project's Quality Management processes.
 Case Study - A famous Program Management guru joined a major consultancy. He
was invited to review the firm's methodology. His first pronouncement was..."you
should have a version number and date on the bottom of every page".

146
 Issue Management – Why, What, How?

 A distinction is sometimes made between different types of issue,

 For example:
 software errors or "bugs" in the developed technical solution,
 more general problems that concern the project team,
 issues that represent a requested change to the system, and
 problems or "bugs" that need to be reported to an external supplier.

147
 Determine Business Impact

 When you report a problem, you are asked to supply a severity level. Use the
following criteria to understand and assess the business impact of the
problem that you are reporting:
 Severity 1 The problem has a critical business impact.
 You are unable to use the program, resulting in a critical impact on
operations. This condition requires an immediate solution.
 Severity 2 The problem has a significant business impact.
 The program is usable, but it is severely limited.
 Severity 3 The problem has some business impact.
 The program is usable, but less significant features (not critical to
operations) are unavailable.
 Severity 4 The problem has minimal business impact.
 The problem causes little impact on operations, or a reasonable
circumvention to the problem was implemented.
148
 Why, What, How?

Issues will arise throughout a project and beyond.

Any potential problem should be surfaced as early as possible and dealt with
efficiently.
Anyone concerned with the project may spot potential problems.
Once an issue is raised, the Project Manager should ensure that it is proactively
pursued and dealt with to the satisfaction of all concerned parties.
It should be easy for the participants to submit their concerns.
It is a good idea to stimulate the submission of issues, possibly by requesting input
as part of the participants' regular progress reporting.
One way this might be done is by including an "issues" section on the project
timesheet.
 Issue  Problem
 There is a temptation to try to avoid trouble by discouraging people from raising
their concerns.
149
 Why, What, How?
 Of course, the opposite is the best policy.
 The participants should be encouraged and rewarded for bringing these to the
attention of the project leadership.
 In some projects, different processes will be defined.
 Alternatively, a single mechanism would present a less confusing interface
for the participants, but would need to support variations in how the issue is
dealt with.
 It is good practice to channel external links through a single point of contact -
either a member of the Project Office, a specialist within the project team, or
a designated person in the wider organization.
 There certainly are some different considerations with issues reported to
external suppliers.
 Very often that supplier will have its own specific procedures, tracking
system, reference numbers, liaison points etc.

150
 Why, What, How?
 Note that the project team will also need to set up a permanent operational
mechanism for the resolution of problems reported by users during the live
running of the system.
 It may be based on the approach used during the project, or it may be that the
organization has a good standard procedure in place.
 There are also some specific stages in a project that might warrant their own
issue management process and system, for example:
 evaluating loosely defined solutions options as part of the conceptual
design thought process,
 evaluating and selecting external service suppliers and systems
components, and
 testing the solution components.
 Although these are more part of the project work than part of the project
management, it may be appropriate to use some of the same techniques
and tools but without the degree of administration and control that should
be found in the project's main issue management process. 151
 Issue Management at the Start of the Project

Relatively little attention to Issue Management is required as part of the Project

Definition work.
It would be normal to agree the overall approach and its importance with the
Project Sponsor and senior leadership.
The main activity at this time would be to establish the mechanism that will be
used, particularly if it involves a system that needs to be selected, acquired and
implemented.
A number of commercial software tools are available.
 The issue management system would normally be part of the same overall set of
procedures and tools that will be used to support the other project management
activities.
 It would also be straightforward to set up your own local system using client
server or web technology.
 In relatively simple projects, the needs could be met by standard tools such as
Email and spreadsheets. 152
 Starting up the Issue Management Process
The issue management process will normally involve a combination of procedures,
responsibilities and systems. The key to success is to have a well-controlled but
easy and efficient process.
Define and agree:
 who does what,
 detailed procedures, forms, tools etc,
 protocols for levels of authority, e.g. what type of corrective action can be
undertaken without reference to the project's senior leadership,
 linkage to other management procedures, e.g. the scope change
management process, configuration management,
 linkage to external supplier's procedures,
 which tools will be used to support and manage the process,
 how to communicate and promote the process and its importance to all
participants.
153
 Starting up the Issue Management Process
Here is a basic process for dealing with issues:
 The first priority is to
identify and capture
the issue.
 It would then be
examined by
an appropriate
member of
the project team to
decide how best to
deal with it.
 Specific actions would be proposed, possibly alternative courses of action to be
compared and agreed.
 Where the issue or action has a significant impact upon the project's benefit
model it would normally need to be referred to the overall project leadership,
probably using the project's scope change mechanism.
 In any event, the impact would be reported to the steering committee.
 The agreed actions are then assigned and carried out, subject to monitoring by
the Project Office followed by a final review and sign off. 154
 Running the Issue Management Process

 The Issue Management process will run throughout the project, and
potentially beyond that into live running.
 Team members and other participants will be encouraged to submit issues.
 The Project Office team and the Project Manager will administer and control
the process.
 It is normal to create standard forms for the submission of issues.
 Although this could be paper based, it is more common to use Email,
client/server or web-based approaches.

155
 Issue Submission Form
Here is an example of a web-based Issue Submission Form.
Take a look at it as a web page

 From a control point of view, it is

important to record the
participants involved, the dates
and the status.
 The Project Office team will
monitor and chase progress.
 The Project Manager will
review the status and take
further action as required.

156
 Issue Submission Form
Where necessary, the issue's resolution will be referred to other bodies such as
the Steering Committee, external suppliers, other specialist departments etc.
It may also be necessary to invoke other management processes such as Scope
Change Control and Configuration Management.
To support the process a variety of enquiries, reports and control documents may
be generated.
The ideal model is a knowledge sharing database accessible by all participants.

157
 Issue Control Log
The most important control tool is a log summarizing the issues, their current
status and who is currently responsible for them, again this may take a variety of
technical forms from paper to a fully integrated database.

This version is a simple Excel file.

158
 Issue Management at Phase End
 The phase-end reporting should include any significant outstanding issues and
will summaries the overall impact on the benefit model.
 Any consequences should be agreed with the Project Sponsor and Steering
Committee.
 Outstanding issues will form an input into the detailed planning process for the
following phase of work.
 Although the project team will be striving to resolve issues in the most
beneficial way, some may remain unresolved at the end of a phase.
 The Project Manager will need to review the status of the outstanding issues
and consider what impact they may have.

159
 Completing the Issue Management Process
The Project Manager and Project Office staff will be reviewing the outstanding
issues on a regular basis and proactively chasing them to conclusion.

By the end of the project there should be no outstanding issue left to resolve.

This does not mean that every issue can be dealt with during the project. It may
be that some concerns cannot be dealt with and appropriate responses should be
made to those concerned.

Other issues may be deferred to be addressed either as part of the live

maintenance of the system or in a future project.

Bear in mind that perfection may be expensive if not unachievable.

It is normal to accept a reasonable level of imperfection where that represents

the best value between cost, benefit, risk and time.

With the amazing pace of e-Solutions, a rapid workable solution is often better
than a high-quality one. 160
 Completing the Issue Management Process

The final status of the issues should normally be reported and reviewed with the
Project Sponsor and project leadership as part of the finalization of the work.
Unsatisfactory conclusions will normally have an impact on the final benefit
model.
Specific actions or requests for future work would be passed into the relevant
management processes.
Dealing with the project's issues and their resolution will have generated new
wisdom and understanding. The individuals concerned should have benefited from
the experience.
It is probably worthwhile spending some time recapping the lessons that were
learnt.
The wisdom should be shared where possible through whatever formal and
informal mechanisms are available for knowledge sharing.

161
 Risk Management
Introduction
• A risk is a potential problem – it might happen or it might not
• Conceptual definition of risk
– Risk concerns future happenings
– Risk involves change in mind, opinion, actions, places, etc.
– Risk involves choice and the uncertainty that choice entails

• Two characteristics of risk

– Uncertainty – the risk may or may not happen, that is, there are no 100% risks.
(those, instead are called constraints)
– Loss – the risk becomes a reality and unwanted consequences or losses occur

162
 Risk Management
Risk Categorization – Approach #1
• Project risks
– They threaten the project plan
– If they become real, it is likely that the project schedule will slip and that costs
will increase
• Technical risks
– They threaten the quality and timeliness of the software to be produced
– If they become real, implementation may become difficult or impossible
• Business risks
– They threaten the viability of the software to be built
– If they become real, they jeopardize the project or the product
• Sub-categories of Business risks
– Market risk – building an excellent product or system that no one really wants
– Strategic risk – building a product that no longer fits into the overall
business strategy for the company
– Sales risk – building a product that the sales force doesn't understand how to
sell
– Management risk – losing the support of senior management due to a
change in focus or a change in people
163
– Budget risk – losing budgetary or personnel commitment
 Risk Management
Risk Categorization – Approach #2
• Known risks
– Those risks that can be uncovered after careful evaluation of the project plan, the
business and technical environment in which the project is being developed, and
other reliable information sources (e.g., unrealistic delivery date).
• Predictable risks
– Those risks that are extrapolated from past project experience (e.g., past
turnover).
• Unpredictable risks
– Those risks that can and do occur, but are extremely difficult to identify in
advance.

164
 Risk Strategies
• Reactive risk strategies
– "Don't worry, I'll think of something"
– The majority of software teams and managers rely on this approach
– Nothing is done about risks until something goes wrong
• The team then flies into action in an attempt to correct the problem rapidly
• (Fire fighting)
– Crisis management is the choice of management techniques

• Proactive risk strategies

– Steps for risk management are followed (see next slide)
– Primary objective is to avoid risk and to have a contingency plan in place to handle
unavoidable risks in a controlled and effective manner

165
 Steps for Risk Management
• Identify possible risks; recognize what can go wrong.
• Analyze each risk to estimate the probability that it will occur and the impact
(i.e., damage) that it will do if it does occur.
• Rank the risks by probability and impact
- Impact may be negligible, marginal, critical, and catastrophic
• Develop a contingency plan to manage those risks having high probability and
high impact.

166
 Risk Identification
Background
• Risk identification is a systematic attempt to specify threats to the project
plan
• By identifying known and predictable risks, the project manager takes a first
step toward avoiding them when possible and controlling them when
necessary
• Generic risks
– Risks that are a potential threat to every software project
• Product-specific risks
– Risks that can be identified only by those a with a clear understanding of the
technology, the people, and the environment that is specific to the software
that is to be built
– This requires examination of the project plan and the statement of scope
– "What special characteristics of this product may threaten our project plan?“

167
 Risk Item Checklist
• Used as one way to identify risks
• Focuses on known and predictable risks in specific subcategories (see next
slide)
• Can be organized in several ways
– A list of characteristics relevant to each risk subcategory
– Questionnaire that leads to an estimate on the impact of each risk
– A list containing a set of risk component and drivers along with their probability of
occurrence

168
 Known & Predictable Risk Categories
• Product size – risks associated with overall size of the software to be built
• Business impact – risks associated with constraints imposed by
management or the marketplace
• Customer characteristics – risks associated with sophistication of the
customer and the developer's ability to communicate with the customer in a
timely manner
• Process definition – risks associated with the degree to which the
software process has been defined and is followed
• Development environment – risks associated with availability and quality
of the tools to be used to build the project
• Technology to be built – risks associated with complexity of the system to
be built and the "newness" of the technology in the system
• Staff size and experience – risks associated with overall technical and project
experience of the software engineers who will do the work

169
 Questionnaire on Project Risk
(Questions are ordered by their relative importance to project success)

1) Have top software and customer managers formally committed to support

the project?
2) Are end-users enthusiastically committed to the project and the
system/product to be built?
3) Are requirements fully understood by the software engineering team and its
customers?
4) Have customers been involved fully in the definition of
requirements?
5) Do end-users have realistic expectations?
6) Is the project scope stable?
7) Does the software engineering team have the right mix of skills?
8) Are project requirements stable?
9) Does the project team have experience with the technology to be
implemented?
10) Is the number of people on the project team adequate to do the job?
11) Do all customer/user constituencies agree on the importance of the project
and on the requirements for the system/product to be built? 170
 Risk Components and Drivers
• The project manager identifies the risk drivers that affect the following risk
components
– Performance risk - the degree of uncertainty that the product will meet its
requirements and be fit for its intended use
– Cost risk - the degree of uncertainty that the project budget will be maintained
– Support risk - the degree of uncertainty that the resultant software will be easy to
correct, adapt, and enhance
– Schedule risk - the degree of uncertainty that the project schedule will be
maintained and that the product will be delivered on time
• The impact of each risk driver on the risk component is divided into one of
four impact levels
– Negligible, marginal, critical, and catastrophic
• Risk drivers can be assessed as impossible, improbable, probable, and
frequent

171
 Risk Projection (Estimation)
• Risk projection (or estimation) attempts to rate each risk in two ways
– The probability that the risk is real
– The consequence of the problems associated with the risk, should it occur
• The project planner, managers, and technical staff perform four risk projection
steps
• The intent of these steps is to consider risks in a manner that leads to
prioritization
• Be prioritizing risks, the software team can allocate limited resources where
they will have the most impact
• Risk Projection / Estimation Steps
1. Establish a scale that reflects the perceived likelihood of a risk (e.g., 1-low,
10-high)
2. Delineate the consequences of the risk
3. Estimate the impact of the risk on the project and product
4. Note the overall accuracy of the risk projection so that there will be no
misunderstandings

172
 Risk Table
• A risk table provides a project manager with a simple technique for risk
projection.
• It consists of five columns
– Risk Summary – short description of the risk
– Risk Category – one of seven risk categories
– Probability – estimation of risk occurrence based on group input
– Impact – (1) catastrophic (2) critical (3) marginal (4) negligible
– RMMM – Pointer to a paragraph in the Risk Mitigation, Monitoring, and
Management Plan

Risk Summary Risk Category Probability Impact (1-4) RMMM

173
 Developing a Risk Table
• List all risks in the first column (by way of the help of the risk item checklists)

• Mark the category of each risk

• Estimate the probability of each risk occurring

• Assess the impact of each risk based on an averaging of the four risk
components to determine an overall impact value

• Sort the rows by probability and impact in descending order

• Draw a horizontal cutoff line in the table that indicates the risks that will be
given further attention

174
 Assessing Risk Impact
• Three factors affect the consequences that are likely if a risk does occur
– Its nature – This indicates the problems that are likely if the risk occurs
– Its scope – This combines the severity of the risk (how serious was it) with its
overall distribution (how much was affected)
– Its timing – This considers when and for how long the impact will be felt
• The overall risk exposure formula is RE = P x C
– P = the probability of occurrence for a risk
– C = the cost to the project should the risk actually occur
• Example
– P = 80% probability that 18 of 60 software components will have to be
developed
– C = Total cost of developing 18 components is $25,000
– RE = .80 x $25,000 = $20,000

175
 Risk Mitigation, Monitoring and Management
• An effective strategy for dealing with risk must consider three issues
• (Note: these are not mutually exclusive)
– Risk mitigation (i.e., avoidance)
– Risk monitoring
– Risk management and contingency planning
• Risk mitigation (avoidance) is the primary strategy and is achieved through a
plan.
- Example: Risk of high staff turnover

176
 Risk Mitigation, Monitoring and Management
• Strategy for Reducing Staff Turnover
 Meet with current staff to determine causes for turnover (e.g., poor
working conditions, low pay, competitive job market)

 Mitigate those causes that are under our control before the project starts

 Once the project commences, assume turnover will occur and develop
techniques to ensure continuity when people leave

 Organize project teams so that information about each development

activity is widely dispersed

 Define documentation standards and establish mechanisms to ensure that

documents are developed in a timely manner

 Conduct peer reviews of all work (so that more than one person is "up to
speed")

 Assign a backup staff member for every critical technologist

177
 Risk Mitigation, Monitoring and Management
• During risk monitoring, the project manager monitors factors that may
provide an indication of whether a risk is becoming more or less likely.
• Risk management and contingency planning assume that mitigation efforts
have failed and that the risk has become a reality.
• RMMM steps incur additional project cost
– Large projects may have identified 30 – 40 risks
• Risk is not limited to the software project itself
– Risks can occur after the software has been delivered to the user
• Software safety and hazard analysis
– These are software quality assurance activities that focus on the identification
and assessment of potential hazards that may affect software negatively and
cause an entire system to fail.
– If hazards can be identified early in the software process, software design
features can be specified that will either eliminate or control potential hazards.

178
 RMMM Plan
• The RMMM plan may be a part of the software development plan or may be a
separate document.
• Once RMMM has been documented and the project has begun, the risk
mitigation, and monitoring steps begin
– Risk mitigation is a problem avoidance activity
– Risk monitoring is a project tracking activity
• Risk monitoring has three objectives
– To assess whether predicted risks do, in fact, occur
– To ensure that risk aversion steps defined for the risk are being properly applied
– To collect information that can be used for future risk analysis
• The findings from risk monitoring may allow the project manager to
ascertain what risks caused which problems throughout the project.

179
 Seven Principles of Risk Management
• Maintain a global perspective
– View software risks within the context of a system and the business problem that is
intended to solve
• Take a forward-looking view
– Think about risks that may arise in the future; establish contingency plans
• Encourage open communication
– Encourage all stakeholders and users to point out risks at any time
• Integrate risk management
– Integrate the consideration of risk into the software process
• Emphasize a continuous process of risk management
– Modify identified risks as more becomes known and add new risks as better
insight is achieved
• Develop a shared product vision
– A shared vision by all stakeholders facilitates better risk identification and
assessment.
• Encourage teamwork when managing risk
– Pool the skills and experience of all stakeholders when conducting risk
management activities

180
 REFERENCES
• Service Management, Fourth Edition, J.A. Fitzsimmons and M.J. Fitzsimmons,
McGraw Hill.

• Service Marketing, Valerie Zeithaml, Mary Jo Bitner, and Dwayne Gremler,

McGraw-Hill.

• Introduction to Operations Research, Hillier and Lieberman

• Service modeling, Principles and Applications. Vilho Råisånen, Wiley

• Understanding Service Business, S.E. Sampson, Wiley.

THANK YOU