Module 1 - Project Initiation

4/28/2019 Laureate International Universities
MODULE 1 - PROJECT INITIATION
Learning Resources
Project Life Cycle and the Project Manager
The Project Management Body of Knowledge (PMBOK®) de nition of a project is: A

temporary endeavour undertaken to create a unique product, service or result.
(PMBOK® Guide – 5th edition glossary)
Every project is unique yet every project evolves through a similar set of phases known
as the project life-cycle. The life-cycle is the transformation of an idea from its
conception, through its development and onward to its actualisation, and therefore, the
end of the project life, i.e. initiation, planning, implementation and closure.
The project team and the project management are the catalysts for the evolution of the
original idea and are responsible for processing and delivery outcomes through the four
standard phases of the project.
Initiation phase
An initiation phase identi es the business opportunity or problem and documents

solutions for its development. The project manager asks questions such as:
What are the project objectives?
How do the objectives tie in to the organisation’s strategies?
Are the objectives feasible?
What does the project include?
What does the project not include?
Who is going to bene t from the project?
https://laureate-au.blackboard.com/webapps/blackboard/content/listContent.jsp?course_id=_68678_1&content_id=_7184745_1&mode=reset 1/21
Who or what is going to in uence or constraint the project? How?
Who or what will be required to develop the project? When? How much will they
cost?
Are those requirements justi able?
What will the project’s success or failure depend on?
Who is going to be accountable for authorisations during the project life-cycle?
How will the project manager document all of the requirements?
When all of those questions have been answered, and when all of the answers have
been documented, a project manager is e ectively outlining the scope of the project.
When the approvals and authorisations have been made and when a project manager
has been appointed, the project can move to the next phase.
Planning Phase
The planning phase is an extension of the initiation phase and develops the details to
achieve the project objectives. The project manager asks questions such as:
What work tasks have to be done?
When should each work task start and end?
Who will perform each work task?
How are we all going to communicate with each other to get the work done?
What other resources will be necessary?
How much is it all going to cost?
How long is it all going to take?
Are we going to produce a quality outcome?
What might go wrong?
By answering all of those questions and co-ordinating all of the tasks necessary to
produce the required outcomes, a project manager is preparing what are known as
scope management and quality management plans and the project can then move to
the next phase.
Implementation/Execution Phase
With all contingencies identi ed and assessed, the project can be implemented and the
project manager can measure performance against initial projections and initiate
corrective or remedial actions when necessary to keep the project on course.
The project manager will ensure that all stakeholders are kept informed of variances,
performance and target achievements during this phase. When all deliverables have
been delivered to and accepted by the client, the implementation phase is over and the
project moves forward to the nal stage.
Closing Phase
The project closure phase involves the involvement of the project manager in:
Termination or transition of human resources
Communication of project closure to stakeholders
Review of project to identify lessons learned and make future recommendations
Completion of all project documentation and handover to client
These four life-cycle phases can be illustrated by a series of steps taken to perform each
phase. This is known as a waterfall model due to the way it is represented graphically.
The waterfall model can be applied to all projects but there are other models which can
be useful for speci c project plans such as, but not limited to:
Agile- essentially used in software design projects and allows for responsive
changes to requirements without providing concrete steps for development.
Spiral – a risk reduction oriented model which breaks up projects into mini-
projects, each addressing one or more risks.
Modi ed waterfall – rather than waiting for each phase to nalise as in the
traditional waterfall model, this model allows for phases to overlap.
Evolutionary prototyping – gathers requirements in multiples, creates planning for

each requirement, each analysis creates the next requirement.
Choosing which model to use is totally dependent on the characteristics of the project
but all will include all project life cycle phases adjusted to the context of the project.
Typically the transition between project life-cycle phases occurs when the project
manager transfers a deliverable to a stakeholder, e.g. documentation, product, report,
etc.
This transition process follows a ow of Plan, Do, Study and Act.
PDSA Cycle
The Plan, Do, Study, Act (PDSA) cycle or Plan, Do, Check, Act (PDCA) cycle was de ned by
Walter Shewhart (1931: 45) and modi ed by his student W. Edwards Deming (1982: 88)
and illustrates how the phases of PDSA are linked together by results.
This cycle is a model for continuous improvement as it maps out a process for
determining the quality of a process and its outcomes.
The continuous improvement cycle is continuously turning causing the wheel to move
up the slope. Once you put an improvement strategy in place and standardise it, the
cycle starts again. The next turn of the wheel may not be immediate. As circumstances
change (e.g. new resources become available or legislation changes), a process can once
again be improved.
Let's apply PDSA in the context of a project. Your role as project manager is to initiate
and lead the continuous improvement process throughout the project life cycle. The
systems you and your team establish should assist to identify and prioritise problems
requiring improvement. The PDSA cycle in a project is usually triggered by an event that
indicates that a required outcome or milestone is not being achieved. Project team
members should be given responsibility for collecting and analysing data, and planning
and implementing action.
You can ensure this happens by:
including these responsibilities in the team members' job descriptions, project

procedures and performance appraisal criteria
putting in place procedures to guide collecting and analysis of data
identifying corrective action to be taken when problems arise
training team members to use the techniques and tools required to collect and
analyse data
empowering them to take action
The gure below illustrates the activities and amount of detail that have to be
managed in any given project to ensure a quality outcome. It is a good idea to
develop a feel for the overall picture of what happens in a project and the relative
importance of the items in any given project.
Some of the activities listed can be quite simple and quick to action in a small project
and very complex and time consuming in a large project. Some can be handled in a few
minutes, others may take a large team several weeks. Some continue throughout the
project life cycle, others, such as recruitment, are done in the development stage of the
project (often with the assistance of human resource personnel). Yet, all of these
contribute in some way to the achievement of a quality project that satis es client and
stakeholder requirements and other constraints imposed on the project.
Continuous improvement may be achieved during a project, but you have to balance
this against the need to deliver on time and within budget. Working with the client and
stakeholders early on is an advantage, but ongoing consultation during the project life
cycle may give you information about those players on which to base decisions about
compromises that have to be made and constraints that must be taken into account.
Stakeholder Analysis
The term 'stakeholders' is frequently used in project management, but what does it
really mean? If we take the de nition of stakeholders provided by the International
Standard AS/NZS ISO 31000: 2009 Risk Management – Principles and Guidelines and
adapt it to the context of project management, stakeholders are:
Those people and organisations who may a ect, be a ected by, or perceive themselves
to be a ected by [our project and its outcomes].
We use the language 'project and its outcomes' in order to capture those stakeholders
who may not be a ected by the project outcomes, but will be a ected, for whatever
reason, by the project works whilst the project is being undertaken.
Stakeholders can be internal or external to the project organisation, e.g. clients, higher
authorities, senior managers of the project organisation, project team members and
external contractors. Once the project stakeholders have been identi ed the project
manager would need to know which stakeholders:
Hold positions of authority in the organisation
Are directly responsible for decisions on important issues
Are in uential in the project
Will be a ected by the project
May hinder or obstruct the project
May support and promote the project
The rationale behind seeking to understand stakeholder requirements is quite simple.

Stakeholders who perceive that the project team is interested in their requirements will
often be more supportive and helpful to the project team; those who sense the project
team doesn't care too much about their requirements are likely to be, at best, indi erent
and, at worst, perhaps hostile to the project.
Di erent stakeholders have di erent levels of importance to the project and therefore
require di erent responses strategies. By prioritising stakeholders and identifying
appropriate ways to respond to their needs, there are two things the project manager is
trying to achieve:
Ultimately, all projects depend on team cohesion amongst all stakeholders. By initially
identifying and analysing stakeholders the project manager can address stakeholder
concerns and give them a sense of ownership and control over their roles and
responsibilities throughout the project. The aim of all stakeholder consultations is to
ensure all contingencies are highlighted before attempting to produce a quality
outcome.
Quality Management Theory
"Quality is free...it’s not doing things right the rst time that is expensive."
W.Edwards Deming
PMBOK® de nes “Project Quality Management” as:
… all of the activities of the performing organization that determine quality policies,
objectives, and responsibilities so that the project will satisfy the needs for which it was
undertaken. It implements the quality management system through the policy,
procedures, and processes of quality planning, quality assurance, and quality control,
with continuous process improvement activities conducted throughout, as appropriate.
The project quality manager will be responsible for documenting a quality plan,
providing quality targets, assurance, and control measures, along with an acceptance
plan, and listing the criteria to be met to gain customer acceptance.
Quality is a widely used word and most of us have formed our own concept of quality.
Advertisements often speak of a product as being of best quality. We think of the
clothes we wear to a formal function as being of better quality than the clothes we wear
to do some gardening or house painting. We might think of a Mercedes Benz as being a
quality car. However, we probably drive something less expensive. Think about it. Both
sets of clothes are appropriate for their particular use. Would you pay more to replace
your car with a Mercedes if your present car satis es your needs? These examples
illustrate how quality is a relative concept and its meaning is di erent in di erent
contexts.
What about quality in the context of project management? When we start planning a
project, we need to get a clear concept of what is meant by quality. Think about these
ideas for a start.
What a client wants may not be what a client can a ord
What a client perceives as quality may not be what a client enunciates as a want.
A client needs to be realistic about the outcomes able to be achieved with the
resources at hand.
Constraints such as time, cost and resources will a ect the quality output.
A project manager needs to estimate very early on in the project, the resources (e.g.
nancial, human, physical) the project will require to achieve a quality outcome.
So let’s look at what de nes quality. When completing a process such as a project, it is
more useful to develop a concept of quality, rather than just focus on de nitions.
Turner (1999: 150) gives us four useful descriptions of a quality project outcome. It:
meets the speci cation
is t for purpose
meets customer's requirements
satis es the customer.
Think about these. Do the last two criteria seem the same? There is a subtle di erence.
Have you ever been to a restaurant and had a meal that you would not complain about,
and at another restaurant had a meal for about the same price that you felt was
special? What was the di erence?
You may have heard of the eight dimensions of quality. The eight dimensions are the
things a customer might reasonably expect in a quality product (or service). This
concept was developed for consumer products, but it provides a useful framework to
help us understand the multidimensional nature of product quality. At some time in our
careers we will probably work on projects where we have to consider some or all of the
eight dimensions.
Total quality management (TQM) is a management philosophy in which:
customer satisfaction is assured by involving the customer in the process
management and workforce work together to achieve quality objectives
responsibility is delegated and workers are empowered to take action to improve

quality
continuous measurement and evaluation are used to guide decision making

(facts, rather than feelings)
continuous improvement and 'Get it right rst time' are encouraged.
With TQM, the inspection process is designed to achieve de ned levels of quality in any
project. A quality outcome is achieved by ensuring that the standards of quality that the
client expects are met, rather than detecting bad quality. TQM is about a commitment
to excellence. From senior management down, everyone is focused on continuous
improvement, teamwork and customer satisfaction. Continuous improvement bene ts
everyone involved in the project and provides those carrying out the project with
improved practices they can use on future projects.
The three main elements of a quality management system are:
It is the responsibility of the project quality manager to ensure all of these elements
work simultaneously to achieve positive outcomes.
Project Scope
Projects don’t fail at the end, they fail at the beginning.
Failures may not be apparent until the end of a project but upon review of the reasons
why the failures happened, indicators often point to ine ective de nition of project
parameters at the beginning of the project. Successful projects are the culmination of a
number of planning and management components. Regardless of what the project’s
objectives are, it is crucial that it be de ned as accurately as possible in the rst stage of
the life-cycle.
This is known as stating a project's scope.
De nition of a project scope focuses on ensuring a project includes everything it needs

to complete the tasks described and does notdo anything outside of the project
boundaries. It de nes the project's objectives, its end products or deliverables and the
principal work activities that are to be carried out.
There is a distinction between project scope and product scope.

It is not uncommon, at this early stage, for a project client to have a somewhat scant
view of their project. There are many reasons for this, not the least of which is that the
people proposing projects are sometimes 'big picture' people for whom detail (at least at
this stage) is not all that important. Whatever the reason for this lack of detail or clarity
of the project deliverables, it is essential that you persist in discussions with the client
until they have given you a thorough understanding of their needs and have committed
to enough details to enable you to develop a thorough and sound project plan.
A mistake often made when establishing project scope is having too little dialogue with
the client. For example, you might speak to the client brie y during the initial stages of
the project, or perhaps receive an email from them outlining their initial idea of their
requirements. Rather than seeking further clari cation, there is often pressure to 'get on
and do the project'.
There are four components that need discussion and consideration when determining a
project’s scope.
It is critical that you determine the project's parameters by documenting those work
activities that are and are not included in the project scope. This ensures that you
contain the e orts of the project team to those things that are actually required and
prevent e ort from being wasted on those things that are not.
It is common for work activities that are included in the scope of a project to be much
better documented than those that are not included. An example of in-scope and out-of-
scope activities are:
INCLUSIONS in Project Scope EXCLUSIONS from Project Scope
Development of customer resource Training of operators in how to use the

management software that is compatible new software
with client’s existing software and will
operate on their computer hardware
Testing of software prior to installation, Changes to software once the nal

and xing any problems testing is completed and any problems
have been xed.
By documenting precise and unambiguous parameters a project manager reduces risk,

e.g. there is a signi cant di erence between:
Testing of the software after installation

and
Testing of the software after installation, and xing any problems.
The identi cation of project parameters includes documenting a project’s constraints

and assumptions.
Constraints are things that are 'known' or 'given' and will need to be taken into account
when the project plan and work breakdown structure are developed.
Examples of constraints could include:
An event deadline, i.e. no extension of time is possible.
A xed budget, i.e. no additional cost can be met.
A set of mandatory functions in a computer software project, i.e. these functions

must be available when the software is implemented, which will a ect both
planning timeframes and testing regime thoroughness.
Compliance requirements, i.e. the outcome of the project must be compliant with
the nominated law, standard, regulation, etc.
Resource restrictions, i.e. the project is only able to access internal resources, or
resources from certain departments
Assumptions are things that are unstated and untested and are capable of causing
project problems because we are not aware of their existence. For example, it is
common to hear expressions like 'everybody understands it to be that way' or 'I was
sure the other party was responsible for that'. Assumptions are often made about
project parameters, and this can cause both the client and the project manager
considerable grief.
Documenting assumptions is a valuable way of getting these sorts of issues out into the
open at the beginning of the project so that they can be discussed and addressed.
One way to identify assumptions is to conduct a brainstorming session with a small
group of people that may include both project team members and outsiders. By
intentionally using a group for this process, rather than having it performed by one
person, you will reduce the risk of overlooking any critical assumptions
Scope Baseline
By identifying in-scope and out-of-scope tasks a baseline can be created from which all
variances to scope can be tracked and managed throughout the project life-cycle. This
baseline will include at a minimum:
Project Scope Statement
Work Breakdown Structure (This will be discussed in Module 4 of Project

Management Principles)
Project Scope Statement
A project scope statement describes in detail the project’s deliverables and the work
required to create those deliverables. It uses active verbs such as deliver, produce,
create to describe objectives. It provides documented understanding of the project
scope amongst all stakeholders. It also provides the scope baseline.
STATEMENT OF PROJECT SCOPE
(Table modi ed from http://www.projectmanagementdocs.com/)
Introduction The purpose of the Project Scope Statement is to provide a baseline

understanding of the scope of a project to include the project’s
scope and deliverables, the work required to complete the
deliverables, and ensure a common understanding of the project’s
scope among all stakeholders.
Project It is important that project stakeholders understand the purpose

Purpose and and justi cation of a project. Projects are conceived to support
Justi cation various business goals and objectives and these must be
communicated to ensure understanding of how the project will
improve business. This also helps stakeholders understand the
investments being made and how this translates into better
business performance.
Scope The Scope Description should include all known characteristics of

Description the project’s product or service. It is important to note that as the
project moves further along in its lifecycle, this scope description
will become more de ned. All details may not be known at the
onset of the project and this may be progressively elaborated as the
project moves forward. This section is key as it serves as a primary
reference for project planning and execution later in the lifecycle.
This section should contain descriptions of what is included in the
product or service as well as the desired outcome of the project.
High Level This section should describe the capabilities to be met by successful
Requirements completion of the project. Depending on the size of the project,
there may be very many or very few requirements. However, during
the creation of the scope statement, it is important to capture, at
least, the high level requirements as many detailed requirements
may not yet be known.
Boundaries Project boundaries are an important part of the scope statement as

they identify what should be included in the project as well as what
should not be included. Without speci c boundaries as a part of the
project scope statement, it is possible to introduce scope creep as
stakeholders may assume certain items to be included in the
project that aren’t clearly stated.
Strategy This section should describe the strategy the project team will use in
executing the project. Depending on the size and complexity of the
project, strategy can di er signi cantly. As the number of
stakeholders, deliverables, and complexity grow, the strategy may
become more di cult to plan. Strategy is sometimes referred to as
the approach the team will take to complete the project.
Deliverables Project deliverables are the products or outputs that project is

intended to produce. Deliverables may also include various reports
or documentation. This section should describe the project’s
deliverables which may be in general terms and not a high level of
detail. During the project lifecycle more detail can be added as it is
determined.
Acceptance Acceptance criteria are the criteria which must be met for the
Criteria project to be considered complete and accepted by management.
This section is important as it sets the expectations of what will and
will not constitute acceptance of the project. Without clear
de nition of what will be accepted, there may be uncertainty across
the project team and stakeholders. Acceptance criteria may be both
qualitative and quantitative.
Constraints Project constraints are limitations that the project faces due to
funding, scheduling/time, technology, or resources. Constraints may
also be physical (i.e. inadequate space or facilities). Constraints
must be carefully planned for and communicated to all
stakeholders as they may require an elevated level of urgency or
exibility to work within and successfully complete the project. This
section should describe the project’s constraints to ensure that all
stakeholders understand the limitations within which the project
must be completed.
Assumptions Project assumptions are factors a ecting the project that we believe
to be true but that we have not veri ed to be true. It is important to
document our assumptions because there is a level of uncertainty
associated with them which introduces risk to a project. This section
should describe the assumptions for the project so all stakeholders
are aware and so that they can be analysed going forward in order
to mitigate risk.
Cost Estimate The project cost estimate is the foundation for budgeting for the
project. It represents an estimate of the funding which will be
needed to successfully complete the project. While all costs may not
be exactly known until later in the project lifecycle, it is extremely
important to develop as accurate an estimate as possible. This
section should provide a project cost estimate with all known details
so that there’s a common understanding among all stakeholders.
Cost Bene t The project cost bene t analysis is a measure of a project’s costs vs.
Analysis its bene ts to determine a course of action most bene cial to an
organization in terms of cost. Projects are undertaken to provide
some bene t to an organization assuming the project is completed
successfully. If there is no bene t provided by a project, then it will
not be approved. However, there must be a quantitative way to
measure the bene t provided by the project. This section must
provide this quantitative analysis and ensure all stakeholders
understand why the project has been approved as well as the
bene ts.
Project Initiation Documentation
The project Scope Statement becomes the most integral part of the project initiation
documentation which must be authorised before a project can be implemented.
Project Initiation Documentation (PID) can include: (depending on the size of the project
or the enterprise guidelines)
Project Goals
Scope Statement
Project Organisation
Business Case
Constraints
Stakeholders
Risks
Project Controls
PID Sign O
Summary
Project Authorisation is the general process of verifying the PID and authorising the
proposed project for initiation and further development.
It is important that the Project Initiation document used is fully understood and agreed
upon by all stakeholders and authorising bodies. This authorisation process con rms
that the project is feasible, cost-e ective, and is ready to move from the initiation to the
planning phase. It allows the project to begin.
Section Summary
Preparation is the key to success when undertaking any project.

Prepare by:
determining exactly what the project sponsor requires the project to deliver
knowing who the key stakeholders are who are likely to impact or in uence the
project
determining the quality expected of the project deliverables
documenting all ndings in detail
formalising authorities to proceed
Topic Resources
The ePMBook by Simon Wallace: http://www.epmbook.com/
Anthony Yeong's Personal Page: http://www.anthonyyeong.com/project-

management.html
PM World Library: http://pmworldlibrary.net/
Projects at Work: http://www.projectsatwork.com/
Max Wideman's Comparative Glossary of Project Management Terms v3.1:

http://www.maxwideman.com/pmglossary/index.htm
All About Project Management:

http://managementhelp.org/projectmanagement/index.htm
Further Reading and Useful Websites
The Role of the Project Manager by Jason Dodd is strongly suggested as a

summary of the roles and responsibilities that e ective project managers have.
The video runs for 17:33 minutes and nishes with a link to download free project
management templates. As part of your studies you should consider gathering
templates and saving the ones you feel are most relevant to your area of project
management for modi cation at a later date. https://www.youtube.com/watch?
v=dUhJuB69ZBo (Accessed 11th November 2015)
Watch this 5:07minute video on The Project Lifecycle in Project Management by

PMP Training for simpli ed explanations of project phases
https://www.youtube.com/watch?v=C9ETcQ0OtUE (Accessed 11th November
2015)
This one won’t take you very long at all! The Deming Cycle in One Minute
summarises PDCA very well. https://www.youtube.com/watch?v=e4gOPeHSRo8
(Accessed 11th November 2015)
What is a Stakeholder? by Making Projects Work is a simple 2:58 minute

illustration to help you identify your stakeholders.
https://www.youtube.com/watch?v=IIeqIN90dK0 (Accessed 11th November 2015)
The Ingredients of Quality Management by CAQ AG (International) is an example

of quality management theory explained in an amusing analogy from real life. This
video is 8:03 minutes duration https://www.youtube.com/watch?
v=h3xyX4yVqzI&list=PLMjhWG4OJdKupbZQk8RFM-gQaFn7wS7tM (Accessed 11th
November 2015)
A very interesting 19:11 minute video - Titanic - Project Management Blunders by

Mark Kozak Holland looks at the story of the Titanic project and examines why the
project failed. This video is a very good summary of this module’s topics and well
worth watching. https://www.youtube.com/watch?v=wbv r2x344 (Accessed 11th
November 2015)
Examples of Project Scope Statements can be found at:
http://onlinelibrary.wiley.com/doi/10.1002/9780470432723.app2/pdf
https://blog.udemy.com/scope-of-work-example/

Module 1 - Project Initiation

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Module 1 - Project Initiation

Diunggah oleh

Hak Cipta:

Format Tersedia

4/28/2019 Laureate International Universities

MODULE 1 - PROJECT INITIATION

Project Life Cycle and the Project Manager

The Project Management Body of Knowledge (PMBOK®) de nition of a project is: A

An initiation phase identi es the business opportunity or problem and documents

What are the project objectives?

How do the objectives tie in to the organisation’s strategies?

Are the objectives feasible?

What does the project include?

What does the project not include?

Who is going to bene t from the project?

Who or what is going to in uence or constraint the project? How?

Are those requirements justi able?

What will the project’s success or failure depend on?

Who is going to be accountable for authorisations during the project life-cycle?

How will the project manager document all of the requirements?

What work tasks have to be done?

When should each work task start and end?

Who will perform each work task?

What other resources will be necessary?

How much is it all going to cost?

How long is it all going to take?

Are we going to produce a quality outcome?

What might go wrong?

Termination or transition of human resources

Communication of project closure to stakeholders

Review of project to identify lessons learned and make future recommendations

Completion of all project documentation and handover to client

Evolutionary prototyping – gathers requirements in multiples, creates planning for

This transition process follows a ow of Plan, Do, Study and Act.

including these responsibilities in the team members' job descriptions, project

putting in place procedures to guide collecting and analysis of data

identifying corrective action to be taken when problems arise

empowering them to take action

Hold positions of authority in the organisation

Are directly responsible for decisions on important issues

Are in uential in the project

Will be a ected by the project

May hinder or obstruct the project

May support and promote the project

The rationale behind seeking to understand stakeholder requirements is quite simple.

Quality Management Theory

PMBOK® de nes “Project Quality Management” as:

What a client wants may not be what a client can a ord

meets the speci cation

meets customer's requirements

satis es the customer.

Total quality management (TQM) is a management philosophy in which:

customer satisfaction is assured by involving the customer in the process

management and workforce work together to achieve quality objectives

responsibility is delegated and workers are empowered to take action to improve

continuous measurement and evaluation are used to guide decision making

continuous improvement and 'Get it right rst time' are encouraged.

The three main elements of a quality management system are:

Projects don’t fail at the end, they fail at the beginning.

De nition of a project scope focuses on ensuring a project includes everything it needs

INCLUSIONS in Project Scope EXCLUSIONS from Project Scope

Development of customer resource Training of operators in how to use the

Testing of software prior to installation, Changes to software once the nal

By documenting precise and unambiguous parameters a project manager reduces risk,

Testing of the software after installation

The identi cation of project parameters includes documenting a project’s constraints

An event deadline, i.e. no extension of time is possible.