LEARNERS’

GUIDE
ICT60315
Advanced Diploma of Information
Technology Business Analysis
ICT PROJECT MANAGEMENT

ICTPMG609
Plan and direct complex ICT projects
ICTPMG603
Manage ICT project planning
ICTPMG606
Manage ICT project quality

VERSION: 1.0
March 2018
 LEARNERS’ GUIDE
ICT60315 Advance Diploma of Information Technology Business Analysis

CLUSTER NAME

ICT PROJECT MANAGEMENT

UNIT CODE AND NAME

ICTPMG609 Plan and direct complex ICT projects

ICTPMG603 Manage ICT project planning

ICTPMG606 Manage ICT project quality

TERM Term , 20 .

ROOM No.

LAB No.

DURATION 180 Hours (20 hours per week for 9 weeks)

TRAINER AND ASSESSOR DETAIL

Name :

Email:
 TABLE OF CONTENTS
LEARNERS' GUIDE .................................1 Work Breakdown Structure .............. 61
Introduction .........................................2 Project Cost Management ................ 64
Competence ........................................3 Project Quality Management ........... 65
Elements ..............................................3 Risk Management ............................. 66
Performance criteria............................4 Project Procurement Management .. 66
Recognition ..........................................4 Project Human Resource Management
Your role in the recognition process ...4 .......................................................... 67
Types of evidence you must present...4 Project Communications Management
Portfolio of evidence ...........................5 .......................................................... 67
Checking your evidence .......................5 Week 3 .............................................. 69
The assessment process ......................5 Quality Planning................................ 70
Course Requirements ...........................6 Quality Objectives............................. 70
Assessment Summary:.........................7 Standards .......................................... 73
Re-assessment & Academic Appeal Gaining Agreement ........................... 73
procedures...........................................8 Cost of Quality .................................. 74
Learning Schedule ...............................9 Quality Criteria.................................. 75
Learning Activities: ............................. 13 Quality Requirements ....................... 77
Risk Management Plan ..................... 77
Week 1............................................... 14
Risk Management Processes ............ 78
Analyse Strategy ................................15
Strategic Planning ..............................16 Week 4 .............................................. 80
Reporting ...........................................22 Project schedule ............................... 81
Review Information ...........................23 Gantt Chart ....................................... 82
Current Information Technology (IT) Schedule Development and Control . 86
Systems ..............................................23 Week 5 .............................................. 88
Compare Advantages ........................24 Financial Management Systems ....... 89
Gap analysis .......................................25 Budgets and Estimating .................... 89
The Business Modeling Process.........29 Financial Baselines ............................ 91
Introduction to Projects ....................34 Week 6 .............................................. 93
What is project management? ..........35 Team Development & Management 94
Project lifecycle .................................37 Tools and Methods ........................... 94
The Constraint Triangle .....................38 MS Project and Human Resources ... 94
Key Players in a Project .....................39 Team management ........................... 95
Project management approaches .....39 Tips for Effective Team Management
Project Management Framework .....43 .......................................................... 95
Week 2............................................... 45 Week 7 .............................................. 96
Project initiation ................................46 Execute and manage the project ...... 97
Stakeholder analysis ..........................47 Provide Leadership and Development
User requirements.............................48 .......................................................... 99
Project governance ............................49 Manage Stakeholders ..................... 100
Broad scope .......................................52 Negotiate Change Proposals........... 101
Project objectives ..............................52 Managing Project Integration ......... 102
Project Proposal ................................55 Integrate Project Outcomes ........... 102
Project Planning.................................56 Consult with Stakeholders .............. 103
Scope Management...........................58 Review and Amend Plans and
Scope Control ....................................60 Contracts......................................... 104
 Monitor Contracts ........................... 104 Week 9 ............................................. 118
Project Management Tools ............. 106 Project closure ................................. 119
Week 8 ............................................ 107 SWOT analysis ................................. 121
Perform quality assurance and quality Project evaluation and follow-up
control ............................................. 108 activities .......................................... 126
Product Performance ...................... 112 Implement project quality
Causes and Compliance................... 113 improvements ................................. 128
Control Techniques ......................... 114 Research and resources .................... 130
Maintaining a Quality Management References ....................................... 130
System ............................................. 114 Books: .............................................. 131
Capturing results ............................. 116 Websites: ......................................... 131
Summary ......................................... 117 Additional Lecture Notes................. 132
LEARNERS' GUIDE

VERSION: 1.0, March 2018 |

© WELLS INTERNATIONAL COLLEGE 1
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 Introduction
This Learner Guide has been developed to assist learners to develop the skills and
knowledge required for the cluster “ICT PROJECT MANAGEMENT” which is consisting of
following units of competency:
 ICTPMG609 Plan and direct complex ICT projects
 ICTPMG603Manage ICT project planning
 ICTPMG606 Manage ICT project quality

This cluster defines the performance outcomes, skills and knowledge required to identify,
plan, control and finalise complex IT projects within small, medium or large organisations. It
also covers planning for quality based on stakeholder needs, implementing quality
assurance processes, and using quality control data to ensure continuous improvement for
the benefit of current and future projects.

This applies to information and communications technology (ICT) senior managers who are
responsible for identifying, planning, controlling and finalising complex projects. The
projects vary across a wide range of ICT, financial, management and business areas. The
environment in which the project is managed is also complex and involves the management
of a project team, which typically will include staff with diverse skill sets. The management
of complex projects also involves significant reporting requirements.

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

2 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
Competence
Competence is a combination of knowledge, technical skills, understanding, problem
solving and attitudes that you need to be successful at work in the ICT industry. The
assessor will assess you against the elements and performance criteria for the relevant unit
of competency.
You may demonstrate your competence by undergoing a formal assessment process or by
presenting a portfolio of evidence for recognition.

Elements
Each unit of competency within a cluster is made up of elements which describe the key
activities of the cluster.

Competency 1 : ICTPMG603 Manage ICT project planning

Elements
 Establish project control plans
 Determine appropriate methodology
 Develop project schedule
 Finalise project budget

Competency 2 : ICTPMG606 Manage ICT project quality

Elements
 Establish a quality management plan

 Perform IT quality assurance processes

 Perform quality control

Competency 3 : ICTPMG609 Plan and direct complex ICT projects IT project quality
Elements
 Identify the strategic and operational needs of the IT project during the planning phase
 Prepare the IT project plan
 Assemble the IT project team and commence work
 Manage the IT project
 Finalise the IT project
 Use the IT project to contribute to improved policies and processes

VERSION: 1.0, March 2018 | Introduction

© WELLS INTERNATIONAL COLLEGE 3
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 Performance criteria
Each element has performance criteria which specify the standards of performance
expected for that element.
To have your skills recognised you need to get a formal assessment through your college.
An assessor can then consider your evidence of:
 paid or unpaid work in Australia or overseas
 on-the-job training
 other qualifications from Australia or overseas
 community or voluntary work
 hobbies, sport and leisure activities

Recognition
Skills recognition means that the skills and knowledge you already have through informal
learning may count towards a nationally recognised unit of competency. You may also hear
skills recognition called Recognition of Prior Learning or RPL.
For skills recognition, you need to prove that you are already competent in that area of
study.

Your role in the recognition process

In traditional training, you are trained to acquire skills and knowledge and through an
assessment process you can prove that you meet the criteria for that unit of competency.
However with skills recognition, the responsibility is on you to find out what competencies
are required and prove that you have them. The trainer or assessor assesses your evidence
and then only trains you in specific areas where you need to fill in the gaps in your skills and
knowledge.

Types of evidence you must present

To prove that you are competent, you must gather and present evidence to your assessor
demonstrating that you already have the skills and knowledge to meet Australian industry
standards.
Your evidence can take many forms including:
 samples, photographs or videos of your work.
 a practical 'on the job' assessment.
 answers to questions in an interview with your assessor.
 a simulation of a work activity.
 letters of validation from your employers.
 performance management reports.
 copies of documents you have completed at work.
 Certificates.
 any other evidence that is valid, sufficient, authentic and current .
You need to work out which types of evidence best demonstrate your competence.

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

4 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
Please contact the Course Coordinator for details on what they require.
You may be required to provide a portfolio of specified work that you have created to a
standard as detailed in the performance criteria for the unit of competency.

Portfolio of evidence
Your portfolio must present evidence as proof of your skills and knowledge that you have
already acquired based on the requirements of the qualification you are seeking.
Your portfolio should include whatever it takes to prove your skills to someone who hasn't
met you before and who understands your industry. Your evidence does not have to be
paper based. A video or demonstration can sometimes be more effective. Think about the
best ways to present your portfolio so that it is easy for an assessor to understand.

Checking your evidence

Make sure your evidence shows that your knowledge and skills are:
 current
 authentic
 valid
 sufficient

The assessment process

The first step for your assessment process is to apply for skills recognition and provide any
physical evidence you have collected. Sometimes, the assessor needs more evidence to
make their decision. This might be because:
 the evidence you provided though strong, did not relate clearly to the units of
competency you applied for.
 you did not give enough evidence of your skills.
 the evidence was not current - you need to show not only that you once had
these skills but that you still do.
 some of the evidence you provided was inconsistent.

The assessor will give you an opportunity to provide more information or demonstrate your
skills and will clearly explain to you what kind of evidence is needed.

VERSION: 1.0, March 2018 | Introduction

© WELLS INTERNATIONAL COLLEGE 5
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 Course Requirements
To be deemed competent in this cluster, a student must
 Attend no less than 80% of scheduled teaching sessions
 Show competency in each performance criterion
 Demonstrate achievement of all learning outcomes.
 Submit and satisfy the requirements of all assessable work.

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

6 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
Assessment Summary:
This cluster consists of the following assessments:

Assessment Assessment Description Due Type of

detail Assessment
Assessment 1 Evidence of identifying the strategic and operational Week 4 Presentation
needs of the IT project and develop a project plan
including scheduling and project control plans like quality
and risk management plan

Assessment 3 Evidence of demonstrating ICT PROJECT MANAGEMENT Week 7 Case Study

ability to finalise project budget, human resource
management and quality management

Assessment 4 Evidence of documentation required throughout an IT Week 9 Research &

project life cycle including evaluation of current system Report Writing
and post project support

Assessment Outcomes
There are two outcomes of each assessment:
S = Satisfactory
and
NS = Not Satisfactory - requires more training and experience.
Students will be awarded
C = Competent on completion of the cluster when satisfied that students have completed all
assessments and have provided the appropriate evidence required to meet all criteria.
If students fail to meet this requirement students will receive
NYC = Not Yet Competent and will be eligible to be re-assessed.
If students are deemed not yet competent and require re-assessment, they will be informed of the
process. If students feel the decision made was in fact incorrect please refer to their student
handbook for information on the assessment appeals process and the steps students are required to
undertake.

VERSION: 1.0, March 2018 | Course Requirements

© WELLS INTERNATIONAL COLLEGE 7
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 Re-assessment & Academic Appeal procedures
Students are notified in advance of assessment dates and times by the member of
staff/trainer responsible for the assessment.
The Following Conditions Apply to Assessments:
1A Students who are absent on the day of assessment must notify the Institute of
their inability to attend prior to the assessment time. A medical certificate must
be supplied.
1B Students who know in advance that an assessment date cannot be met must
inform the member of staff/trainer responsible for setting the assessment.
Students, who have missed an assessment for any reason covered under these conditions,
must apply for the missed assessment to be rescheduled.

The Following Conditions Apply to Re-scheduled Assessments:

1) Students must have rescheduled and completed the assessment within four (4) weeks of
the beginning of the following term.
2) Students must organise to reschedule the assessment with the Trainer responsible for the
assessment.
3) Students must supply a medical certificate as states in condition 1A
4) If a student has previously attempted an assessment twice and has been deemed NOT YET
COMPETENT they may apply for the Re-assessment and the fee will apply.

If conditions 1, 2, 3 or 4 are not adhered to, students will be deemed NOT YET
COMPETENT.

Re-Assessment Procedures
A Re-assessment form is available on student lanyard or on the website.
For Re-assessment and rescheduled assessment dates please check with the trainer or the
student notice board.
5) Please submit the completed form to the Course Coordinator for an approval before
making any payment. All Re-assessments undertaken must be approved by the Course
Coordinator.
6) Course Coordinator will keep a record of the Rescheduled / Re-assessment.
7) Student will need to make a non refundable payment of $200.00 per unit after an approval
from Course Coordinator.
8) Notify the Course Coordinator 24 hours in advance if the student is not able to complete
the re-assessment/s for any reason

Appeals for Re-assessment

If a student is dissatisfied with the results of an assessment they may lodge an appeal for
re-assessment of the evidence of competency for which the assessment was undertaken.

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

8 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
Learning Schedule
Week# Topic Lesson Detail

Week 1 Identify strategic and operational Analyse Strategy

requirements
Compare Information
Introduction to Projects
Report
Project management approaches
Review Information
Compare Advantages
Determine Objectives
Clients requirements
Document Findings
How does a project start?
What is a project?
Characteristics of Projects
What is project management?
Project lifecycle
The Constraint Triangle
Outcomes of a Project
Successful Projects
Key Players in a Project
Stakeholders
Project Manager
Project management approaches
The Project Life Cycle
Why a Project Management Approach?
Why is PM a Popular Business Method?
Project Management Framework
The 9 functions of project management
The traditional PM approach

Week 2 Project initiation Initiating processes

Project Planning Project purpose and justification
Scope Control Stakeholder analysis
Identifying Stakeholders
Analysing Stakeholders Needs
User requirements
Project governance
Determining Governance Structure
Project Organisation Charts

VERSION: 1.0, March 2018 | Course Requirements

© WELLS INTERNATIONAL COLLEGE 9
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 Key Governance Roles and Responsibilities
Managing expectations
Broad scope
Project objectives
Clarifying Objectives
Generating and evaluating options
Project proposal
Scope Management
Scope Definition
Work Breakdown Structure
Project Cost Management
Project Quality Management
Project Time Management
Risk Management
Project Procurement Management
Project Human Resource Management
Project Communications Management

Week 3 Quality Planning Quality Objectives

Risk management plan ISO 9000
Examples of quality objectives
ISO 9126
ISO 9126 as a reference for Quality Objectives
Aligning Quality Policies, Objectives and Processes
Standards
Gaining Agreement
Methods, Tools and Techniques
Making the tool/technique selection
Five major costs related to quality
Cost of Quality
Quality Criteria
ISO 9126
Quality Requirements
Areas of risk
Risk Management Processes
Risk Matrix - a risk management tool

Week 4 Project schedule Activity Sequencing

Schedule Development and Control Activity Duration Estimating

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

10 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 Gantt Chart
How to Produce a Gantt Chart
Interpretation of a Gantt Chart
Manual Method for Producing a Gantt Chart
Using MS Project
Critical Path Analysis
Project tracking
Critical Path
Producing the critical path

Week 5 Financial Management Systems Budgets

Budgets and Estimating
Types of budgets and their uses
Financial Baselines
Cost Control

Week 6 Team Development & Management Tools and Methods

MS Project and Human Resources
Team management
Tips for Effective Team Management

Week 7 Execute and manage the project Integrate project activities

Project Management Tools Provide Leadership and Development
Manage Stakeholders
Resolve Disputes
Project Management Tools
Negotiate Change Proposals
Integrate Project Activities & Aspects
Consult with Stakeholders
Review and Amend Plans and Contracts
Monitor Progress
Review Objectives and Achievement

Week 8 Perform quality assurance and Measuring throughout the Project

quality control
Triggers and schedules
Project schedule
Example Project schedule
Product Performance
Test Report
Causes and Compliance
Classifying defects

VERSION: 1.0, March 2018 | Course Requirements

© WELLS INTERNATIONAL COLLEGE 11
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 Control Techniques
Maintaining a Quality Management System
Capturing results
Reporting to management
Status reports
Progress reports
Project forecasting

Week 9 Project Closure Closeout management activities

SWOT analysis Finish the Work
Handover the product
Gain Acceptance for the Product
Project completion report
Summary or Overview
Performance against Scope, Objective, Schedule,
Budget and Quality
Project Management Aspects
Recommended Improvements
The internal environment
Resources
The External Environment
Industry Environment
Competitor Environment

Project evaluation and follow-up Analyse Project Outcomes

activities
Support Arrangements
Implement Project Quality
Post Project Review (lessons-learned)
Improvements
Business Benefits or Post-Implementation Review
Continuous Evaluation & Improvement (Status)
Review
Continuous Improvement
Quality improvement standards
Determine the quality effectiveness
Lessons Learned

NB- “Daily Lesson Plan” aligning above lesson strategy need to be developed and provided
to the Course Coordinator prior to the commencement of the cluster.

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

12 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
Learning Activities:

VERSION: 1.0, March 2018 | Learning Activities:

© WELLS INTERNATIONAL COLLEGE 13
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 Week 1

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

14 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
Identify strategic and operational requirements
Business strategy is a planning function of any organisation. Business strategy incorporates
having a strategic plan.

Analyse Strategy
The strategic plan of an organisation sets out the goals a business hopes to achieve within a
specified period of time. It also helps the organisation understand the environment within
which they operate and the market forces that affect them.
An analysis of the current strategic plan enables you to understand the goals of your
organisation. However, in order to analyse the strategic plan you first need to understand
the structure and purpose of a strategic plan. This topic describes the elements that make
up a strategic plan.

What is Strategy?
Strategy can be defined as:
"A plan of action resulting from strategy or intended to accomplish a specific goal".
In a business context we define strategy as having some sort of goal for the future.

What is Strategic Planning?

Strategic planning then can be defined as:
"Determining long-term objectives by analysing the strengths and weaknesses of an
organisation, studying opportunities and threats in the business environment, predicting
future trends and projecting the need for new products and services."
Source: Schwalbe (2010).
"Strategic planning is the process of identifying long term organisational goals, strategies
and resources. Strategic planning looks beyond day-to-day activities and focuses on a
horizon that is 3, 5, 10, or 20 years into the future."
Source: Murch (2000)
Strategic planning is a task that all organisations perform. For smaller businesses this may
be a very informal process. The manager or owner of the business may decide the goals and
objectives of the business.

Example
 The owner of a business may decide that the business needs to update its computer
hardware over the next 10 months.
 The manager may decide that their organisation needs to have a presence on the
internet, either in the form of:
A brochure site [Link]
An e-commerce site [Link]
The strategic plan will set out how these objectives will be achieved.

VERSION: 1.0, March 2018 | Week 1

© WELLS INTERNATIONAL COLLEGE 15
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 Larger organisations however, approach strategic planning more formally. Strategic
planning will usually be performed by management and / or the board of directors in an
organisation.
Strategic planning is not something that the organisation completes once a year, or once
every three years. It is an ongoing and evolving process that does not finish once the
strategic plan is written. An organisation should constantly be scanning its environment to
gather information about new trends, competitors and its industry surroundings.

Strategies are Unique

It is very important that the circumstances of the organisation be fully understood, when
developing a successful strategic plan. It is not enough to simply 'borrow' strategies from
other organisations.

Task
Take a few minutes to think about real life examples of where businesses have successfully
borrowed strategies from each other.

Example
 Many organisations have decided to have their own presence on the internet
because that is what their competitor has done. If the organisation is simply copying
their competitor without understanding their environment and the needs of their
customers, then they are wasting valuable resources.
 PepsiMax differentiated itself from other sugar-free soft drinks by not portraying
itself as a diet drink. The success of the PepsiMax approach has resulted in attempts
by competitors to reposition sugar-free drinks to a younger, more active market
through the use of almost identical promotional strategies.
 There has been a rapid spread of drive through facilities at fast food outlets. Drive
through has also moved to other types of businesses including liquor stores and
smoke marts.
The strategic plan helps the organisation to produce desirable outcomes. It does not call for
wide business diversification or acquisition of other businesses. It focuses on greater
efficiency in manufacturing, better provision of service, or greater effectiveness in
marketing and management. It calls for maximising returns from current technologies and
markets and extending the competitive advantage that the organisation has over
competitors.

Strategic Planning
Strategic planning means preparing the best way to respond to the circumstances of the
organisation's environment and whether or not its circumstances are known in advance.

Example
 Non-profit organisations must often respond to dynamic and even hostile
environments
 Often businesses must respond quickly to changes in their environment, i.e. broken
down equipment, new legislation, competition (both new and old), interest rates,
the value of the Australian dollar, staffing problems, etc.

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

16 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
Being strategic means:
 Being clear about the organisation's objectives.
 Being aware of the organisation's resources.
 Incorporating both into being responsive to a dynamic environment.

In the strategic planning process, an organisation's purpose, vision and values shape its
mission statement, which leads to goals, objectives, business operations and results that
affect the stakeholders of the organisation.
Source: Shelley and Cashman, et al., (2003)

Pitfalls in Strategic Planning

Strategic planning is a very important process for every organisation, but there are many
pitfalls that should be avoided.

Problems with Strategic Planning

The following problems are encountered in organisations where strategic planning is not
regarded as an important activity, or not enough time has been put into the process:

Inability to activate new strategy

Implementing a new strategy usually requires the organisation to change its management
systems, culture, skills, resources or structure. If all of these had to be changed at the same
time, many managers might be unable to cope with the complexity of the situation. This
may lead to them not implementing the strategy.

Inability to develop a strategic response

In some cases, even if the organisation is aware of the trend, it may not be able to respond
appropriately. This may be due to an inability or an unwillingness to change the managerial

VERSION: 1.0, March 2018 | Week 1

© WELLS INTERNATIONAL COLLEGE 17
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 approach of the organisation. It may also be the result of structural or organisational
inflexibility.

Allowing corporate politics to dictate priorities

Individuals in the organisation may be aware of future trends, but the information may not
be placed on the agenda because:

 Managers may be too busy with operational issues to give time to significant
trends.
 Managers may decide not to give the information to the organisation as a
whole, because they perceive the power of their knowledge over others. This
internal politics can reduce the ability of the organisation to respond to
environmental change.

Failure to see a strategic challenge

Many organisations do not scrutinize their external environment and are therefore
unaware of significant trends that will impact on future operations. This can be caused by
introverted thinking from top management, by focusing inwards too much to solve
technical or organisational problems. Such managers neglect to examine external
environmental factors, for example, the potential of new competitors.

Failure to understand the challenge

Although the organisation may identify the major trends in their environment, they may
not understand the magnitude of the issue or how to respond to it effectively.

Which Strategic Planning Model is Best?

Many books and articles describe how best to do strategic planning.
In this resource we will be following a model that has four basic steps:

1. Identifying
Identifying involves looking at the organisation's current mission and vision (if they have
one!), in order to understand their core business.

Mission and Vision

A mission statement is like an introductory paragraph. It must communicate the essence of
the organisation to the reader. An organisation's ability to articulate its mission indicates its
focus and purpose.

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

18 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
A mission statement typically describes an organisation in terms of its:
 Purpose - why the organisation exists and what it seeks to accomplish.
 Business - the main method or activity through which the organisation tries to fulfil
this purpose.
 Values - the principles or beliefs that guide an organisation's members as they
pursue the organisation's purpose.

A mission statement summarises the what, how and why of an organisation's work. A vision
statement presents an image of what success will look like, i.e. how the organisation will
effectively carry out its operations.
Vision is a type of aim that is less specific. Vision is usually defined as a desirable future
state where details have not yet been determined. The vision statement presents a
description of how the organisation will or should operate at some point in the future and
how the customers or clients will benefit from the organisation's products or services.

2. Diagnosing
Assessing the Situation
Once an organisation has committed to why it exists and what it does, it must take a look at
its current situation. Part of strategic planning is an awareness of the resources available to
the organisation and an idea of future trends that may occur. This will enable the
organisation to respond to changes in its environment.
Situation assessment means obtaining current information about the organisation's
strengths, weaknesses and performance (opportunities and threats). This information will
highlight the critical issues that the organisation faces and that its strategic plan must
address.
These could include a variety of primary concerns, such as funding issues, new program
opportunities, changing regulations or changing needs in the client population, changes in
technology, problems with information systems, changing needs of customers and so on.
The point is to choose the most important issues to address. The strategic plan should
focus on no more than five to ten critical issues.

Environmental Analysis
Environmental analysis is the method used to perform situation assessment. The purpose
of environmental analysis is to identify significant characteristics that exist within the
industry environment. By identifying these characteristics the organisation can make
decisions regarding which of these areas will be critical to their future success.

Example
Environmental analysis consists of two major components.
1) The External Environment
An examination of the external environment will determine outside forces that
influence the organisation.
2) The Internal Environment
Investigation of the internal environment will establish internal factors that influence
organisation strategy and sources of competitive advantage the organisation has.

VERSION: 1.0, March 2018 | Week 1

© WELLS INTERNATIONAL COLLEGE 19
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 One of the major tools of environmental analysis is the SWOT analysis.

3. Conceiving
Strategic Analysis
It is important to first review the environmental analysis you conducted on the
organisation, in particular you will need to review the opportunities and threats (from the
external environment) and the strengths and weaknesses (from the internal environment).
With the elements of the SWOT analysis (ie, strengths, weaknesses, opportunities, threats),
you are trying to find relationships between them. These related elements will be grouped
together.

Finding Relationships
Relationships between SWOT elements may have two forms
1) You can group together several Strengths (or Weaknesses, or Opportunities, or Threats), that
are about the same issue, to form a single organisational Strength.
2) When the elements relate to the same issue you can match:
a. Strength to Opportunity
b. Weakness to Opportunity
c. Strength to Threat
d. Weakness to Threat
Linking one of these elements may reduce the effect of the other. For example, by
enhancing weaknesses in the organisation we may be able to reduce threats.
Each of these groupings forms a critical issue that the organisation faces.
The strategic plan will have up to ten critical issues that are being addressed. The strategic
objectives are created for each of these critical issues.

Strategic Objectives
"Strategic objectives are those objectives that refer to and affect, the entire organisation
and deal with the relationship between the organisation and its environment."
Source: Viljoen and Dann (2000, pg 618)
Strategic objectives, like all objectives should be SMART objectives, that is, the objectives
should be:
 Specific
 Measurable
 Attainable
 Relevant
 Timely
In creating each strategic objective you must come to a conclusion or response about what
the organisation will do as a result of the major issues facing them. This will be written in
the form of a goal, or what the business is hoping to achieve.

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

20 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
Performance Targets
When setting performance targets, take each strategic objective in turn and specify the
requirements which enable the strategic objective to be achieved.
The performance targets are written in the form of tasks that need to be achieved.

4. Realising
Action Plans
Action planning is carefully laying out how the strategic goals will be accomplished. You will
be specifying activities and listing the expected results which enable the strategy to be
implemented. Action planning also includes stipulating responsibilities (who needs to do
what) and timelines (when). You should also include how you will monitor and evaluate the
objective using performance indicators.

Compare Information
An examination and comparison of the current strategic plan of the organisation and their
operational practices will enable an organisation to highlight information technology gaps
and improvement opportunities.

Current operational practices

The current operational practices of an organisation may include the policies they have in
place, the procedures they follow to complete tasks, or the system they use to perform
day-to-day processing. The system used by the organisation may be a manual, or paper-
based system; a computerised system that incorporates hardware, software and
networking capabilities; or a hybrid of the two: partially computerised with some manual
processes.

Examine current strategic plan

The strategic plan of an organisation sets out the goals a business hopes to achieve within a
specified period of time. It also helps the organisation understand the environment within
which they operate and the market forces that affect them.
Examination of the current strategic plan enables you to understand the goals of your
organisation and how those goals will be achieved. The model followed in this resource
presents each critical issue with the following four elements:

Example
Four Elements of Critical Issues
 Strategic Analysis: lists SWOT elements to highlight a critical issue
 Strategic Objective: the goal the organisation wants to achieve
 Performance Target: To do list of what the organisation wants to achieve
 Action Plan: Specific activities that enable the strategy to be implemented

VERSION: 1.0, March 2018 | Week 1

© WELLS INTERNATIONAL COLLEGE 21
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 IT gaps between current practices and future goals
By examining the current strategic plan and current practices of the organisation, it may be
possible to see some gaps. The gaps may be in what the organisation currently does and
what they hope to do in the future. By identifying gaps the organisation may be able to
determine improvement opportunities.

Example
An organisation currently has a database that has a table for customers, customer orders
and customer invoices. This database has been used successfully for the last two years. The
following may represent the results of a gap analysis performed for this organisation.

Example: Gap Analysis

Objectives
To evaluate the current database functionality, to determine processing gaps.
Findings
An environmental analysis produced the following weaknesses and opportunities:
Weakness
 The database does not capture information about our suppliers or our purchasing patterns
from different suppliers.
 We are unable to adequately compare suppliers to see if we are getting the 'best deal' from
each of them.
Opportunities
 A new supplier has approached us with cheaper prices and loyalty discounts.
Implications
A gap exists between what the database can currently do and what the organisation would
like it to be able to do. Currently no supplier data is recorded in the database, all
information is kept manually. This makes comparison between different suppliers difficult.
Recommendations (if required)
The organisation must create and implement a strategic goal that enables expansion of the
database to incorporate new features.

Reporting
Reporting is an important process that allows the appropriate personnel, including line level
management or higher management, to examine the results from projects, surveys and
research.
Reporting can be defined as:
1) An account presented usually in detail
2) A formal account of the proceedings or transactions of a group
3) To make or present an often official, formal, or regular account
4) To write or provide an account or summation for publication or broadcast - report the news
5) To submit or relate the results of considerations concerning - the committee reported the bill.
Source: [Link]

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

22 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
Types of Reports
The report may contain all the details of a project you have been working on, or surveys or
research you have been conducting. Formal reporting may include a formal presentation to
senior management or a board of directors about your outcomes, conclusions and
recommendations. Alternatively you may need to prepare a gap analysis, which will be
included in a larger report. A gap analysis often has the findings of your examination, the
implications of the gap and a recommendation for alignment.
Reports come in many different formats. They may be written reports, or presented
verbally to a group of people, management, a client or a board of directors. The following is
a brief list of different types of reports. Many more than this exists.
 Organisation policies and procedures
 Feasibility report
 Evaluation report
 Recommendation report
 Technical report
 Research report
 Business plans
 Technical specifications
 User manuals
 Strategic plans
 Test plans
 User documentation
 Progress report

Summary
Reports are a way of presenting a set of data in a specified format. There are many
different types and styles of report. Reports may be in writing, or presented verbally to a
client, a group of stakeholders, a supervisor, a manager or a board of directors.

Review Information
Most organisations have in place some sort of information technology system. In order for
a gap analysis to be performed successfully, detailed knowledge of the current information
technology system must be understood.

Current Information Technology (IT) Systems

Information technology can be defined as:
Applied computer systems - both hardware and software and often including networking
and telecommunications, usually in the context of a business or other enterprise. Often the
name of the part of an enterprise that deals with all things electronic.
Source: [Link]
The current IT system may include an entire information system, or it may be components
within an information system. These components may include:
 Hardware
 Software

VERSION: 1.0, March 2018 | Week 1

© WELLS INTERNATIONAL COLLEGE 23
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
  Web page
 Network
 Telecommunications
 Information
 Documents
 Files
Changes may occur within one or more of these components of the information system, eg.
upgrades of hardware, modification of documents, etc. The change may also be for the
information system as a whole. For example, modifications may need to be made to the
information system due to new legislative requirements, like the GST, which ensured that
all businesses in Australia had to modify their financial systems to be compliant.
Most organisations will have some sort of IT system already in place. This system is often
referred to as the 'legacy system' of the organisation.
When performing a review of the legacy IT system, a list of system components may be
generated. This list will detail all of the current hardware, software and other network
infrastructure in place in the organisation.
An example of a limited list of legacy system components is shown below:

Example

Hardware Quantity
Held
 Processor, Intel Pentium 4 2.8 GHz, 800 MHz FSB
 Memory, 128 MB, 333 MHz DDR SDRAM 1
 Hard Drive, 40 GB ultra ATA100 5400 rpm 1
 3.5" 1.44MB diskette drive 1
 Optical Drive, 20x min./48x max. CD-ROM drive 1
1
 Video, Integrated Intel Extreme Graphics 2, 64 MB
1
Video Memory 1
 Mouse & Keyboard, PS/2 Wheel Mouse, 104+ 1
Keyboard (QWERTY) 1
 Network Adapter, Integrated Intel® 10/100/1000
Ethernet (Gigabit) adapter
 Modem
1
Software - 1
1
 Operating System, Microsoft Windows XP 1
Professional
 Application Software, Microsoft Office Basic Edition
2003
 LANDesk Software, Intel LANDesk Client Manager
Software v6.3
 Anti-Virus Software, Norton Anti-Virus, Norton
Internet Security 2004

Compare Advantages
All information technology systems will have both advantages and disadvantages. A new
system will usually seem better to some users, because it is different to the system
currently in place. This new system may purport to have better functionality than the
'legacy' system. Other users may like the familiarity of the 'legacy' system and may fear

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

24 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
possible changes being introduced. Gap analysis is one method used to compare legacy and
proposed information technology systems. Gap analysis allows an organisation to recognise
the features and functionality of the legacy system, compared with the requirements of the
new system.

Gap analysis
Gap Analysis is all about evaluating and improving business performance. In information
technology, gap analysis is the study of the differences between two different information
systems or applications, often for the purpose of determining how to get from one state to
a new state. A gap is sometimes spoken of as "the space between where we are and where
we want to be." Gap analysis is undertaken as a means of bridging that space.

Gap Analysis Steps

A gap analysis may include the following steps:

1. Review System
Review of the current information system or application in order to understand the
processing, features or system currently in place.

2. Develop Requirements
Development of the requirements needed by the 'new system'. This may be in the form of a
strategic objective that the organisation wishes to implement. This strategic objective may
allow the organisation to increase their competitive advantages, or improve the technology
and efficiency of their practices and procedures.
The proposed system may include:
 Restructuring the current information system in order to become compliant with a new
industry standard or organisation requirement

VERSION: 1.0, March 2018 | Week 1

© WELLS INTERNATIONAL COLLEGE 25
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
  Updating the hardware of the system. For example, the current hardware may be outdated,
inefficient and unable to handle the capacity needs of the organisation.
 Updating the software of the system. The applications used by the organisation may not
have the functionality required. There may be a newer version of the software that
incorporates added features and is a 'better fit' for the organisation's requirements.
 Restructuring of documents, files or information so that it is more accessible.
 An e-commerce website that enables customers to purchase products online.
 New technology may become available, ie, a new invention, or reduction in price of a
product to be more affordable for the organisation. This 'new technology' may enable the
organisation to improve efficiency or productivity.
 Creating new applications for use by the organisation. For example, a new database may
need to be created to contain all of the organisation's data.

3. Comparison
A comparison of the current element of the system and the new system requirements or
objectives will give an idea of whether a 'gap' exists. If there is a gap there will be
discrepancies between what the organisation wants and what they already have in place.
The gap analysis allows us to discover how to get from one state to a new state. This
comparison may take the form of a 'Gap - Yes/No' column (see Example gap analysis table
below), to identify where the gaps exist for each element.

4. Implications
Implications of introducing the item being evaluated. The risks and impacts of introducing/
implementing the item.

5. Recommendations
The last step in the gap analysis is to make recommendations to identify the items or
solutions needed to 'fill' the gap, if a gap exists.

Example gap analysis table

The gap analysis table shown below is an example of a template that can be used to
conduct a gap analysis.

Example: Gap Analysis Table

Currently in place Requirements Gap Y/N Items needed

 Computers (hardware)
manual 'paper based' computerised
Y  Applications (software)
information system system  User training

Etc...

Limited Gap Analysis Template

The template shown below, is another example of a gap analysis template. This is the
template that will be followed hereon in. This template can be used to record the
information gathered from the gap analysis.

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

26 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 Example: Another Gap Analysis Table

Objectives

Test/ check/ evaluate/ confirm a specified condition or situation.

Findings

The results of performing the test/ check/ evaluation/ confirmation

Determine Objectives
Changes to any part of the information technology system will have implications. These
implications may be positive, or negative. Positive implications may include increases in
efficiency and reductions in costs of using the system. Negative implications will be the risks
of implementing the changes. Risks may include end users not using the system effectively
and the new system not performing as expected.
There are 5 different steps of Gap analysis. They are:
1) Review of the current system
2) Determination of requirements for the proposed system
3) Comparison of the two systems to determine gaps
4) Implications of the gap
5) Recommendations

Implications
The impact / risk involved with the item being evaluated must be determined. The item
may have both positive and negative implications associated with it. The implications of
each item may be presented in the form of a list of dot points, which outline the impact or
risks of the item.

Example

A new piece of software is going to be introduced in the organisation

Risks/ implications:

 The current hardware must have the capacity to allow the new software to run effectively
 If the software has not been used in the organisation before, then user training must take
place, to ensure the end users are able to operate the software
 A help desk may need to be put in place to support the end users of the software
 There may be licensing issues that need to be explored by the organisation

Recommendations
The last step in the gap analysis is to make recommendations to identify the items or
solutions needed to 'fill' the gap, if a gap existed.

VERSION: 1.0, March 2018 | Week 1

© WELLS INTERNATIONAL COLLEGE 27
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 The recommendation may be a description of what is required in order for the organisation
to put the new system in place. For example, if the current system uses a manual 'paper
based' information system and the requirement is to computerise this system, a gap exists
between the legacy system's performance and the strategic objectives of the organisation.
We may recommend that the organisation needs to purchase new hardware and software
and have user training for all end users involved in performing tasks in the proposed
system.

Document Findings
Documentation of findings and reporting information to management is an important
process. It allows management to evaluate all relevant information and make informed
decisions about the most appropriate course of action for the organisation.

Gap Analysis Template

Many different formats are used to display gap analysis information. The example gap
analysis table and the gap analysis template (below) show two possible alternatives for
presenting this information.

Objectives

Test/ check/ evaluate/ confirm a specified condition or situation.

Findings

The results of performing the test/ check/ evaluation/ confirmation

Implications

The impact/ risk involved with the item being evaluated

Recommendations (if required)

Actions or solutions to be implemented

Confirm Requirements
A 'system' could be a website, application/s, hardware and the associated procedures.
Information Technology is a very broad term that includes things like distributed and
centralised database applications, websites, telephone systems, point of sale systems,
printers, faxes, mobile phones and any other electronic device you might think of.
Often when you have helped a business implement a new system, you will also be asked to
help support the system. This competency will help you develop a systematic approach to
identifying the technology to be supported, negotiating an agreement, developing support
procedures and providing quality support in accordance with your agreement.

Obtain Client Acceptance

In terms of project management, client acceptance and sign off is part of the administrative
closure of the project which has produced the system. To obtain administrative closure all
performance measurement documentation (qv. test reports and supporting evidence),

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

28 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
product documentation (qv. test success confirmation) and other records must be
produced to verify completion.
If appropriate, the client acceptance should be endorsed by client advocates. These
advocates may include the business' customer service people, marketing people,
production areas, legal representatives and so on.
Client acceptance and sign-off involves transfer of system ownership and responsibility to
the client.
Client acceptance and sign off is a formal process leading to product handover and payment
to the developer. The acceptance and sign-off should be in a documented format, either
hard copy or electronic.
Most often, the processes of confirmation of test success, obtaining client acceptance and
sign-off occur simultaneously.

The Business Modeling Process

Business Analysis or Business Modeling helps the analyst understand and visually depict a
business. It also helps in developing Business Use Case Models, Business Analysis Models,
Domain Models and the organizational context for the Business. The following diagram
outlines the business analysis process followed at O2I while devising a business analysis
software solution.

Assess Business Status

The goal of assessing business status in the Early Inception Phase is to get a strong indicator
of where your organization or organization processes currently stand in relationship to the
vision statement you have articulated. Your software implementation strategy will be based
on the gap between the current status of your organization or organization processes and
your vision.
Assessing your business status is not a one-time event. It is important that you continually
assess your current software business status. Don't assume that there is a clear end-point in
the process. It is important to stop and look at pre-determined points to judge the extent to
which the plan has been successful.

VERSION: 1.0, March 2018 | Week 1

© WELLS INTERNATIONAL COLLEGE 29
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 These are the following activities and results carried out during this phase.
Activities Key Resulting Factors
Capture a Common Business Vocabulary Business Vision
Maintain Business Rules Target Organization Assessment
Assess Target Organization Business Glossary
Set and Adjust Objectives Business Rules
Identify Business Goals Business Goals
Define the Business Architecture

Describe Current Business

The goal of this process is to understand your current business. It looks at what the vision
statement of your business is and identifies your target audience. It also studies the plans
made to achieve your business vision.
This process also identifies the users of the system and the functions that each user
executes that would contribute to the success of your business. It also considers the

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

30 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
business goals for each user within the system and the rules that govern the user in
achieving these goals as defined in the Business.
These are the following activities and results carried out during this phase.
Activities Key Resulting Factors
Assess Target Organization Target Organization Assessment
Find Business Actors and Use cases Business Vision
Set and Adjust Objectives Business Analysis Model
Find Business Workers and Entities Business Architecture Document
Capture a Common Business Vocabulary Business Use Case Model
Define the Business Architecture Business Use Cases
Maintain Business Rules Business Use Cases Realization
Identify Business Goals Supplementary Business Specifications
Business Glossary
Business Rules
Business Goals

Identify Business Process

The goal of this process is to clearly articulate the business processes that are defined to
help an organization achieve their business objective and business vision. This process is
essential for the management to effectively identify real organizational constraints, and
allocate appropriate resources to relieve those constraints.
Once these business processes are identified and well defined, it provides a powerful
means to reproduce the company's goals and objectives. This in turn aligns the thinking of
the personnel and management accordingly.
The purpose of any business is to convert investment into profit. An organization that
invests its time in defining these business processes has covered half of its investment in
profit.
These are the following activities and results carried out during this phase.
Activities Key Resulting Factors
Maintain Business Rules Business Vision
Set and Adjust Objectives Business Architecture Document
Define the Business Architecture Business Use Case Model
Capture a Common Business Vocabulary Business Use Cases
Find Business Actors and Use cases Supplementary Business Specifications
Identify Business Goals Business Glossary
Business Rules
Business Goals

VERSION: 1.0, March 2018 | Week 1

© WELLS INTERNATIONAL COLLEGE 31
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 Refine Business Process Definitions
The goal of this step is a more detailed definition of the business processes, that can be
understood by someone outside the organization. This step describes from an external
viewpoint what the processes are, without including internal details such as information
structures or the roles involved. Typically, this is done through text documents, although
some also illustrate business process flows with simple activity diagrams.
These are the following activities and results carried out during this phase.
Activities Key Resulting Factors
Detail a Business Use Case Business Use Case Model
Review Business Use Case Model Business Use Cases
Structure the Business Use Case Model. Supplementary Business Specifications
Review Record

Design Business Process Realizations

The goal of this step is a description of how roles collaborate to perform the process, and
what information objects are used, managed, or produced. This is where you get into the
details of the process and start building the business analysis model.
These are the following activities and results carried out during this phase.
Activities Key Resulting Factors
Capture a Common Business Vocabulary Business Glossary
Find Business Workers and Entities Business Analysis Model
Define the Business Architecture Business Use Cases Realization
Maintain Business Rules Business Architecture Document
Business Rules

Refine Roles and Responsibilities

The goal of this step is to identify all the key business roles and responsibilities in every
identified business process. The following are the activities and results carried out during
this phase.
Activities Key Resulting Factors
Define a Business Entity Business Worker
Review Business Analysis Model Business Entity
Business Event
Review Record

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

32 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
Explore Process Automation
The goals of this step are to identify possible business process automations (BPA). BPA is
the process of integrating enterprise applications, reducing human intervention wherever
possible, and assembling IT services into end-to-end process flows. As a significant part of
business process reengineering, BPA improves operational efficiencies and reduces risks.
These are the following activities and results carried out during this phase.
Activities Key Resulting Factors
Set and Adjust Objectives Business Vision
Define Automation Requirements Business Analysis Model
Business Use Case Model
Supplementary Business Specifications

Develop a Domain Model

The goals of this step are to create and validate a domain model that matches the business
needs to the real life scenario. Developing a domain model also captures the most critical
business rules for the Business Process. Modeling key concepts or business entities and
their relationships clarifies the team's understanding of the problem to be solved. It allows
the team to uncover subtle complexities early on, as well as establishes a common
vocabulary.
A domain is an area of knowledge or activity characterized by a family of related systems.
The domain model is a subset of the Business Object Model. A domain model captures the
most important Business Entity abstractions (modeled as UML classes) within the context of
the domain. A domain model does not include any business worker definitions.
These are the following activities and results carried out during this phase.
Activities Key Resulting Factors
Maintain Business Rules Business Rules
Capture a Common Business Vocabulary Business Glossary
Define a Business Entity Business Entity
Find Business Workers and Entities Business Analysis Model
Review Business Analysis Model Review Record

The function of business analysis is critical in the success of a software project. The process
needs to be continuous, from the start to the finish.
The business analyst plays an important role in every stage of the software development
life cycle and ensures that the solution that emerges out of the whole process meets the
business goals of all the stakeholders involved.

VERSION: 1.0, March 2018 | Week 1

© WELLS INTERNATIONAL COLLEGE 33
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 Reporting
The results of a gap analysis are important to the management of an organisation for a
number of reason:
 Management have all information about a number of possible changes to the
information technology system
 Management can evaluate all relevant information
 Implications of each change are presented along with a recommended course of
action
 The gap analysis allows management to make more informed decisions
As a result of feedback from management the organisation will generally choose a course of
action that best suits their situation. There may be financial or other resource constraints
that management take into account when choosing a course of action.

Example
Results from the gap analysis may include a recommendation that the organisation upgrade
their computer network and hardware to improve system efficiencies and to allow network
traffic to be processed more quickly. This will involve replacing certain network
components and other hardware.
After evaluating this recommendation, management may decide that although this is the
best course of action for the organisation to take, they simply do not have the funds to
implement it. It may be decided that the upgrade will be postponed for six months, or only
a limited version of the upgrade will take place.
This management feedback determines the course of action taken by the organisation.

How does a project start?

The majority of projects undertaken each year are identified during the annual IT Strategic
Planning process. From time to time projects are approved outside of this process in
response to changes in the organisation’s objectives or to accommodate changes in
legislative requirements etc. However, there is no project until the project is approved and
funded by management. To achieve this proposed project must be embodied in a
structured way.

Introduction to Projects
What is a project?
The Project Management Institute (USA) in the Guide to the Project Management Body of
Knowledge (PMBOK) defines a project as “A temporary endeavour undertaken to create a
unique product or service”. (PMI 2000) Typically a project is a one-time effort to accomplish
an explicit objective by a specific time. Unlike an organisation’s ongoing operations, a
project must eventually come to a conclusion.
Projects are undertaken at all levels of the organisation. They may involve a single person
or many people. Their duration may range from a few weeks to more than five years.
Projects may involve a single unit of one organisation or may cut across organisational

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

34 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
boundaries. Projects are critical to the success of organisations today as they are the means
by which organisational strategies and changes are implemented.

Examples include:
 Developing a new product or service
 Effecting a change in structure, staffing or style of an organisation
 Designing a new transportation vehicle
 Developing or acquiring a new or modified information system
 Constructing a building or facility
 Implementing a new business procedure or process
 Organising a Conference

Characteristics of Projects
It is generally accepted that all projects have the following characteristics:
 Has a lifecycle (i.e. phases)
 Have a defined timescale (specified start and end date)
 Specific objectives
 Time and cost constraints
 Approved budget
 Limited resources
 Definable tasks
 Deliverables (specific end result)
 Unique set of activities (do not involve repetitive processes)
 Involve an element of risk
 Achieve beneficial change

What is project management?

The Project Management Institute (USA) in the Guide to the Project Management Body of
Knowledge (PMBOK), define project management as “the application of knowledge, skills,
tools and techniques to project activities to meet project requirements” (PMI 2000).
A systematic approach to the management of projects, regardless of size, duration and
complexity, helps the project manager to apply a degree of structure to the project, to
manage the inherent risks and to achieve successful completion of the project.

Project management has the following benefits:

 It ensures that the product which the project is to deliver is clearly defined and
understood by all parties
 It enables the objectives of the project to be clearly defined and closely aligned
to the business objectives of the organisation
 It promotes a logical approach to planning and encourages more accurate
estimating of time, cost and other resources
 It provides a consistent means to monitor and control.

VERSION: 1.0, March 2018 | Week 1

© WELLS INTERNATIONAL COLLEGE 35
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 Project typologies
Projects can be categorised according to how well defined the goals are and the methods
for achieving those goals. This categorisation leads to four types of projects. By
understanding what type of project you are embarking on, you can adopt an appropriate
process to initiate your project.
The following Goals and Methods Matrix was developed by Turner and Cochrane and is a
useful method for identifying different types of projects.

Type 1
 Goals and methods are well defined at the beginning (e.g. engineering projects)
 Possible to move quickly into planning the work to be done
 Emphasis is on activity-based planning
 Earth Projects as they are well defined with a solid foundation

Type 2
 Goals are initially well defined, but the methods of achieving them are not (e.g.
product development projects)
 Functionality of the product is known but how it will be achieved is not known
 Point of the project is to determine how to achieve the goals
 Not possible to plan activities because the project will determine them
 Milestone planning is used where the milestones represent components of the
product to be delivered
 Water Projects as they are like a turbulent stream. They flow with a sense of
purpose, but in an apparently haphazard way.

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

36 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
Type 3
 Goals are not well defined initially, but the methods are known (eg some
software development or information systems projects)
 Difficult to specify the user’s requirements as the goals are known to exist but
cannot be specified precisely until the users begin to see what can be produced
 Milestone planning is used where the milestones represent the completion of
life-cycle stages
 Fire Projects as much heat can be generated in the definition of the work, but
they can burn with no apparent purpose

Type 4
 The goals and the methods of achieving them are poorly defined (eg research
and development projects, some organisational change projects)
 Planning may use soft systems methodologies
 Milestone planning is used where the milestones represent gateways, go/no-go
decision points
 Air Projects as they are very difficult to catch hold of and deliver “blue-sky”
research
 Objectives

Project lifecycle

The project lifecycle is the process by which the project is undertaken. Each project has a
definite start and finish and goes through several life-cycle phases. Understanding the
phases that a project passes through and the requirements of each phase provides a useful
framework for the Project Manager. There is widespread agreement in the project
management literature that there is a 4-phase and basically sequential generic Project Life
Cycle. This 4-phase model is most appropriate for Type 1 projects. More phases may be
required for Type 2, 3, or 4 projects.

A senior manager in the relevant work unit completes a preliminary phase where the
project purpose and justification is determined. Once this has been approved, a staff
member is assigned the role of Project Manager and an official file is created. The Project
Manager then continues the initiation & concept phase.

VERSION: 1.0, March 2018 | Week 1

© WELLS INTERNATIONAL COLLEGE 37
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 All projects are a balance between 3 main things
 The resources or materials you have and their cost.
 The project’s (product’s) specification – what it is supposed to do. (E.g security
alarm system for a house)
 Time – the project’s schedule.

The Constraint Triangle

RESOURCE
(COST)

PRODUCT
(SPECIFICATION)

SCHEDULE (TIME)

Outcomes of a Project
 Meet the time, quality, performance and cost expectations of the project
sponsors and stakeholders
 A successful project
o Meets or exceeds the customers requirements (expectation and
satisfaction)
o Is delivered on time
o Within Budget

Successful Projects
 WELL DEFINED OBJECTIVE
o Scope (objectives are clear and reasonable)
o Schedule (All Steps are broken into time frames)
o Cost (every part of the project has a budget)

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

38 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
  E.g. introduce to the market-in 10 months & within a budget of $50,000 – a new
coffee machine that cuts the time of making coffee by one half.

Key Players in a Project

 Project Sponsor (E.g: Building a house could be the owner) – the person
ultimately responsible for the products or services that the project intends to
deliver. Designates responsibility to manage all activities to the project manager.
 Stakeholders – those individuals or organisations either involved in, or
significantly affected with or by the project (New computer system – Guest).

Stakeholders
 Sponsor –(person who decides on the idea) initiates the project, supports the
teams senior members. (General Manager)
 Project steering team- a group of project sponsors who monitor the status of all
active projects. (Sporting event – security company, transportation, game
assosiation)
 Project Manager – leads the project team and delivers the project goals
 Team member- performs specific actions required in the project
 Client-person owning the project
 Suppliers – delivers the goods and services required by the project. Provides
logistical support.

Project Manager
Responsible for:
Work Quality
Human Resources Time
Communications Costs

Effective Project Managers

 A sound understanding of stakeholder (owners/partners) issues and processes
o what does the customer want?
 A team builder
o creating team spirit, setting goals motivating the team
 An effective organiser
o planning, communicating, scheduling, reviewing, monitoring & replanning
are vital skills

Project management approaches

The Project Life Cycle
 Projects are “born” when a need is identified by the customer.
 Project life cycles vary in length, from a few weeks to several years.
 Not all projects formally go through all four phases of the project life cycle.

VERSION: 1.0, March 2018 | Week 1

© WELLS INTERNATIONAL COLLEGE 39
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 PROJECT LIFE CYCLE

CONCEPT PROGRESS

SCHEDULE OUTCOME

Project Life Cycle – Stage One CONCEPT

 Project is conceived
 Preliminary (beginnings) goals discussed
 Problems raised that might be faced.
 Potential benefits identified.
 Alternative approaches researched
 Provisional costings determined

Project Life Cycle – Stage One CONCEPT –Activities

 Define stakeholders
 Clarify project boundaries. (The maximum limits on every aspect of the project)
 Authorities and reporting arrangements
 Determine resource availability
 Project risks
 Alternatives
 Budget estimates
 Initial approval to begin project

Project Life Cycle – Stage Two SCHEDULE

 All the work required by the project is scheduled.
 Objectives are finalised
 Resources are assigned or chosen.
 Quality is signed off on
 Final costings are approved
 Timing agreed on

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

40 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
Project Life Cycle – Stage two SCHEDULES –Activities
 Work Breakdown schedule.
 Activity dependencies.
 Timelines.
 Estimating durations.
 Gantt charts.
 Monitoring plans.
 Critical path analysis.
 Float calculation (Time wastage).
 Detailed project budgeting.

Project Life Cycle – Stage three PROGRESS

 Project has commenced
 Emphasis is now on tracking actual progress
 All work is monitored, controlled and corrected where necessary
 Schedules are reviewed, revised and updated

Project Life Cycle –Stage three PROGRESSES –Activities

 Briefing the team
 Record keeping
 Plans for managing project finance, human resources, physical resources
 Verifying performance standards
 Communicating progress
 Purchasing materials & equipment
 Managing changes within activities
 Implementing risk plans

Project Life Cycle – Stage four OUTCOME

 The project is completed and handed over to customer
 Resources are disposed of, or reassigned
 Project is evaluated, reports written
 Administration (paperwork) of project is completed

Project Life Cycle – Stage four OUTCOMES –Activities

 Check financial records
 Reassign project staff
 Complete project documentation & handover
 Review project outcomes against scope & plan
 Document lessons learnt from project

VERSION: 1.0, March 2018 | Week 1

© WELLS INTERNATIONAL COLLEGE 41
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 Project Life Cycle

Why a Project Management Approach?

• Project management helps organizations meet their customers’ needs by
standardizing routine tasks and reducing the number of tasks that could potentially
be forgotten. Project management ensures that available resources are used in the
most effective and efficient manner. Project management provides senior executives
insight into “what is happening” and “where things are going” within their
organization.

• Many organizations around the world such as NASA, IBM, AT&T, Siemens, Chiyoda
Corporation, PricewaterhouseCoopers, Singapore Computer Society, and the State
Government of Oregon (USA), utilize project management to enable innovative
processes, to plan, organize and control strategic initiatives, to monitor enterprise
performance, analyze significant deviations and forecast their impact on the
organization and project(s).

Application of Project Management

 The application of project management principles enables senior executives to:
o Establish measures of success
o Enable customer focus and alignment
o Quantify value commensurate with cost
o Optimize the use of organizational resources
o Incorporate quality principles
o Put strategic plans into practice
o Ensure fast time-to-market

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

42 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
Why is PM a Popular Business Method?
 Project management also has gained popularity over the last several decades
because of significant changes in the workplace. Some of these changes include:
o Downsizing (i.e. fewer people to do more tasks)
o Projects and services have grown larger and more complex
o Fierce global competition
o Easier access to information through vast communications networks
o More sophisticated customers demanding higher quality goods and
services
o Exponential technological growth
o Multinational organizations seeking to establish uniform practices for
managing projects

Project Management Framework

The 9 functions of project management

 Scope: Identifies the objectives of the project, as well as what will be
included/excluded in the project.
 Time: The phases, activities and tasks required to complete the project.
 Cost: The revenues and expenses incurred as a result of undertaking the project.
 Quality: How well the project is managed, as well as the quality of the project
outcome.
 Risk: Any event that may threaten the project from achieving its objectives.
 Human Resource Management: Staff required to complete the project.
 Communications: The processes required to distribute project information.
 Contracts and Procurement: The acquisition of goods and services for
completing the project.
 Integration: The art of project management. Integration balances the other 8
competing areas

VERSION: 1.0, March 2018 | Week 1

© WELLS INTERNATIONAL COLLEGE 43
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 The traditional PM approach

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

44 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
Week 2

VERSION: 1.0, March 2018 |

© WELLS INTERNATIONAL COLLEGE 45
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 Project initiation
Initiating processes
Initiating the project means setting up the project from the idea or inception and making
sure it is the right project, in the right place, at the right time, for the right purpose.
Initiating processes for small projects or part of a larger project include:

 Clarification of the project purpose and justification

 Stakeholder - needs analysis
 Determination of the Broad Scope
 Establishment of clear and shared project objectives
 Establishment of project governance structures
 Documentation of this process as the Project Proposal

In some projects where all of the above have been clarified it is possible to continue straight
on to planning the project. However it is important to check whether all the key
stakeholders (i.e. Project Owner, Project Sponsor, Steering Committee and/or Project
Board) are in agreement on all of the points listed above before proceeding to the planning
stage.
Research indicates that most projects that fail have either skipped the project initiation
phase altogether or have been through inadequate initiation processes. In many cases the
more obvious objectives such as "on time" and "on budget" were emphasised at the
expense of other more important and often not immediately apparent objectives (eg
functionality or quality objectives).
The project is initiated or defined to determine its viability. Essentially, a GO/NO GO
decision about its viability needs to be made by the end of the initiating process. For
instance this might be a decision as to whether a sustainable commitment can be made to
the necessary resources if the project is to proceed.
The steps for initiating the project will be presented in sequence; however, in reality this is
an iterative process. You will find that in many cases you will need to go back through these
steps several times until you have initiated or defined the project and have obtained a
satisfactory level of agreement about the project objectives.
Agreement is essential. If agreement from all key stakeholders in all the areas listed above
is not obtained the chance of failure is high. When issues are contentious the level of
agreement sought might be agreement to carry on with the project in spite of residual
disagreements about particular issues. This must be documented.

Project purpose and justification

It is always a risk to run a project that does not have a sound purpose and clear objectives.
The justification and validity of the project needs to be confirmed before the project
proceeds, otherwise the time, cost and quality of the project can be compromised. You
clarify the purpose and justification with your Sponsor to establish the following:

 Justification of the project in relation to the organisation’s strategic plans

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

46 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
  Priority of the project in relation to other projects that might be competing for
funds or resources
 Line of authority (sign-off) regarding project expenditure
 Requirements for project reporting
 Escalation procedure if risks are triggered
 If there are any other related or dependent projects/ work being undertaken that
might have an impact on your project
 If any decisions have already been made or any work has already been done in
relation to your project
 If there are any ethical considerations
 The benefits that the Sponsor hopes to achieve by the project

Stakeholder analysis
The success of a project often depends as much on the stakeholders and their perceptions as it
does on the project manager and the real work. As projects are initiated in response to identified
needs and opportunities in a specific environment or context, you need to identify the
stakeholders early in the project.

A stakeholder is anyone who has a vested interest in the outcome of the project and who will judge
the success or failure of the project, including:

• Client/Owner the organisation whose strategic plan created the need for the
project or the person who requires the project to be
undertaken (NB maybe the same person as the Project Sponsor)
• Sponsor the person who is providing the funds and has the ultimate
authority over the project
• End-users the people who will actually use the deliverables of the project
• Champion a senior user who campaigns for the project
• Project Manager person with the authority to manage the project
• Project team members the group that is performing the work of the project

Identifying Stakeholders

To help you identify all the stakeholders in a project, talk to your Sponsor in the first
instance to get an initial list of stakeholders. Use the following to assist you in identifying
who should be included:
 Who are you doing the project for?
 What functions or people might be affected by the project’s activities or
outcomes?
 Who do you report to?
 Who authorises expenditure?
 Who contributes resources (people, space, time, tools and money) to the project?
 Who wants reports/updates?
 What is the risk to the project of omitting a particular stakeholder?

VERSION: 1.0, March 2018 | Week 2

© WELLS INTERNATIONAL COLLEGE 47
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 When you meet with each of the identified stakeholders, ask them who else should be
involved. If the list is too long, classify the stakeholders into:

Core: People actively involved in the project doing the work

Primary: Stakeholders who must be engaged during the project
Secondary: Stakeholders who should receive communications about the project.

Analysing Stakeholders Needs

Once you have identified and classified all the Stakeholders, ask them to spell out exactly
what success of the project means for them. Remember that as their interests vary, their
needs are likely to differ. For each of the identified Stakeholders, ask the following
questions:
 What do they want/need/expect?
 What criteria will they use to judge project success?
 What will make the project a success for them?
 What stake do they have in the project? (I.e. how engaged are they in the
project?)

How do you find out what Stakeholders need?

 Ask them (Face to face, email, telephone, memo, exception ask)
 Use personal knowledge (It is dangerous to assume that you know what is in
other people’s heads so it is better to check with the person.)
 Get information from others: Delegate the task of finding out the needs to
 Managers/Supervisors (NOTE: This is also dangerous and needs to be managed.
You need to be very specific about responsibilities, deadlines, and quality of
information)
 Make sure that you confirm the needs you have identified with each of the
Stakeholders/ Stakeholder groups.

User requirements
(This step may not be needed if your project requirements are clear and straightforward)
The user requirements of the project must be defined and documented. Approval and
confirmation must be obtained before the project can proceed. To obtain agreement about
needs:
 Separate needs from wants
 Group the needs that are similar
 Prioritise needs (eg essential, nice to have)
 Identify any conflicting needs
 Negotiate agreement between stakeholders with conflicting needs

This process often requires a number of meetings with stakeholders. Stakeholders often
express their needs in terms of a particular product or solution to the problem, which has

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

48 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
created the need for the project in the first place. It is important to re-state the agreed
needs in terms of “what the end product/service(s) of the project should do”.

Stating the agreed needs in functional terms permits the project manager to offer a range of
solutions to the client or key stakeholders. If the project outcomes are restricted to
solutions offered by key stakeholders too early in the analysis process important alternative
options might be overlooked. Document the final set of agreed requirements and obtain
sign-off from all key stakeholders.

Project governance
Project governance refers to the system of decision-making and management that has been
established for a particular project. For some projects an elaborate decision-making and
governance structure will be in place from the beginning while for others, the governance
structure will need to be established.
Effective governance ensures that:
 The project lifecycle is managed and the benefits are realised
 The outcomes are aligned with business needs, balanced against the desires for
interested parties
 Risk profiles are managed to acceptable levels
 Project deliverables meet the planned timelines, cost and quality
 The scope and milestones for go/no-go are managed
 The organisation has the capacity and capability to utilise the delivered outcomes
 Appropriate project management methodologies are used
 Variations are approved

Determining Governance Structure

When determining the governance structure for your project, ask the following:
 Who is ultimately responsible for the project?
 Who is accountable?
 Who has the authority to sign-off?
 What committees/boards do you need to negotiate with? In what order? What
do they need to know? What are the limits of their authority/responsibility?
 To whom can you escalate the project if a quick decision is needed?

Project Organisation Charts

Organisation charts are useful tools to show the relationship of people and structures, which
govern and influence the project. A project organisation chart can be used to define:
 Reporting relationships and responsibilities
 Connections between groups affecting the project
 Project political structures

VERSION: 1.0, March 2018 | Week 2

© WELLS INTERNATIONAL COLLEGE 49
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 Example of a Project Organisation Structure

Key Governance Roles and Responsibilities

Project Client/Owner
 The person who requires the project to be undertaken
 Accountable for the overall success of the project

⇒ Maybe the same person as the Project Sponsor

Project Sponsor/Project Director/Project Board/Steering Committee

 Senior management of the Project
 Accountable for the successful delivery of the project
 Has authority to commit resources
 Ensures the project is addressing a genuine business need and that the project
solution is consistent with that need
 Ensures assumptions, constraints and expectations remain valid and relevant
 Champions the cause of the project
 Makes decisions about the Project
 Provides guidance and support to the Project Manager
 Resolves issues escalated by the Project Manager
 Accountable for the funds allocated to the project

⇒ The Project Sponsor is usually a senior manager from the work unit in which the
project is taking place.

⇒ The Project Board usually includes representatives from all the significant
stakeholder groups

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

50 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
Project Manager
 Responsible for the day-to-day running of the project within defined authorities
for cost and schedule
 Develops and maintains the project plan
 Ensures project deliverables are provided to scope, time, budget and quality
 Manages project resources
 Manages stakeholder communication and project reporting

Manager of the Project Manager

 The operational or line manager who the Project Manager reports to on a day-to-
day basis

Project Team Members

 The staff who will be doing the actual work

Reference Group or Working Party

 Provides advice and recommendations

⇒ Does not have the authority to make decision

Roles, responsibilities and authority must be negotiated and understood by all

stakeholders.

Managing expectations

“Stakeholders represent the lifeblood of a project. The perceptions of your stakeholders

strongly influence the status of your project. If the stakeholders are feeling confident in the
project purpose and status and their expectations for the project’s impact on the
organisation are uniform, the project is probably in good shape. Should any stakeholders
have issues about the intent of the project, or should the stakeholders be out of sync
regarding the priorities for project deliverables, the overall status of the project could be in
jeopardy.”
(McGannon 2005)

Successful management of your project depends upon how well you manage the
relationship of the people and structures that govern and influence your project. It is not
uncommon in projects for influential stakeholder groups to assume control beyond their
level of designated authority, resulting in negative consequences for the governance of the
project. It is also not uncommon for key stakeholders to change during the project and for
existing stakeholders to change their minds about important issues. You will not be able to
prevent this but it must be managed. Managing expectations requires constant
communication with key stakeholders to ensure that there are no nasty surprises.

VERSION: 1.0, March 2018 | Week 2

© WELLS INTERNATIONAL COLLEGE 51
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 Broad scope
The scope is what the project contains or delivers (i.e. the products or services). When
starting to plan the scope of the project think about the BIG PICTURE first! At this level it is
best to concentrate on the major deliverables and not to get bogged down with detail.
It is just as important to agree on what is OUT OF SCOPE as it is to define what is IN SCOPE
as stakeholders will often have different ideas regarding what is supposed to be IN the
project and what IS NOT. Obtain agreement up front to avoid unnecessary disputes later
on. This is a useful task to conduct with key stakeholders and can help clarify issues at any
time in the Initiation or Planning phases. Generally speaking assumptions and constraints
will generate risks to the project that must be managed. Examples of areas that could be
examined and clarified include:
 The type of deliverables that are in scope and out of scope
 The major life-cycle processes that are in scope and out of scope
 The types of data that are in scope and out of scope
 The data sources that are in scope or out of scope
 The organisations that are in scope and out of scope
 The major functionality that is in scope and out of scope

During this process issues may not be resolved to the agreement of all key stakeholders at
one meeting. Any unresolved issues should be noted at the end of the document for
elevation to top priority for discussion at subsequent meetings until resolution is achieved.

Project objectives
The success of your project will be defined by how well you meet your objectives. The more
explicitly you state your objectives at the outset, the less disagreement there will be at the
end about whether you have met them. Remember that at this early stage of the project,
there are still many “unknown factors”. Be prepared to revise your objectives as you gather
more information about what you need to achieve.

In project management we are constantly juggling time, cost and quality and we refer to the
relationship between time, cost and quality as the TCQ triangle or the triple constraint (also
known as the Sanity Triangle). If you change one, it has an effect on the other three. For
example: If you shorten the amount of time you have to complete the project, you must
either increase the cost or lower the quality.

Writing Project Objectives

Project objectives are concrete statements that describe what the project is trying to
achieve. Objectives should be developed for time, cost, quality (or functionality) and should:
 Be aligned to business objectives
 Be measurable
 Be achievable

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

52 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
  Be consistent
 Be readily understandable
 Be few in numbers
 Have the full support and commitment of senior management, key stakeholders,
project sponsor and users

A well-worded objective is SMART Specific

 States exactly what the project is to accomplish
 Phrased using action words (such as “design”, “build”, “implement”)
 Limited to those essential elements of the project that communicates the
purpose of the project and the outcome expected

Measurable
 If you can’t measure it, you can’t manage it
 In the broadest sense, the whole objective is a measure of the project; if the
objective is accomplished, the project is a success
 Build several short-term or small measurements into the objective
 Watch out for words that can be misinterpreted such as improve, increase,
reduce customer satisfaction, etc.

Agreed
 Each objective has the full support and commitment of senior management, the
project sponsor and users.

Realistic
 Considering all the other demands and projects in my life, is it doable?
 The learning curve is not a vertical slope
 The skills needed to do the work are available
 The project fits with the overall strategy and goals of the organisation

Time-framed
 Objectives must be achieved within a definite timescale/deadline
 Timescales should be set in consultation with the objective holder.
 To make an impact, timescales need to be set down in specific terms no matter
how far distant they are.

Some Project Managers say that the most effective project objective is between 25 and 50
words – if in doubt, check with your Project Sponsor.

Clarifying Objectives
Regardless of whether you have been provided with the objectives for your project or you
have written them yourselves, you need to clarify them by asking the following:

VERSION: 1.0, March 2018 | Week 2

© WELLS INTERNATIONAL COLLEGE 53
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
  Are the objectives clear?
 What other questions need to be asked?
 Who would have the information?
 How will you best obtain the information you need to clarify the objectives?

Objective Examples

Develop a Project Management Guide based on the Project Management Body of

Knowledge and
National Competency Standards for Project Management by 15 July 2009 at a cost of
$20,000.
Develop and implement the 2009 PM@UTS Learning Program in accordance with learning
and development standards for a goods and services cost of $7,000. The Program is to be
advertised by 28 February and fully implemented by 30 November 2009.

(In some cases a budget or time frame has not be assigned at this stage of the project so you
must simply state that the “time frame and/or budgets are to be determined”. These will be
determined during the planning phase of the project.)

Generating and evaluating options

(This step may not be required if your project is well-defined)

Now that you have carefully defined the measurable objectives for your project it is time to
explore a broad range of options for the delivery of your project. You might have to work
through a range of options or different approaches to identify what the end product might
be and who will deliver the project.

The range of options or alternative approaches available to you will depend upon what
decisions have already been made by others with respect to the project. For instance the
organisation might have existing supplier agreements, which will restrict what kind of
equipment you will be able to use in the project, or there might be a limited range of
suppliers. Budget restrictions might eliminate the possibility of using outside contractors to
do the work.

Generating Options

When generating alternatives:

 Identify what has already been decided about the project

 Brainstorm/list all the possible options
 Use the big picture approach – consider
o Not doing the project

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

54 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 o Redefining it
o Different forms of procurement
 Shortlist the options that meet the objectives for closer evaluation
o Sort the options into positive, interesting and negative
 For each positive/interesting option, ask:
o What will satisfy the needs?
o How should it be delivered?
o Who will deliver it?

Evaluation of Options/Alternatives

The options or alternatives for the delivery of the project should then be evaluated against
the:
 project objectives, in terms of time, cost and quality
 risks involved
 extent to which the required scope of the project is addressed.
 the impact of the options or alternatives on the various stakeholders.

The process of evaluation of options will be more or less formal depending upon the nature
of the project. Evaluation might simply require a round table discussion and agreement. In
projects, which incur high risks to the organisation, a formal evaluation process must be
adopted and carefully documented for approval by senior management.

In some cases estimates in terms of time and cost will be required from potential suppliers
before evaluation of options can be completed. Time must be set aside to allow for these
estimates to be obtained. The degree of accuracy of time and cost estimates will depend
upon the amount and accuracy of information that can be given to suppliers. It may not be
appropriate, at this stage in the project, to dedicate extensive resources to gathering the
information required – this will result in a relatively low level of accuracy of the forthcoming
estimates. As the project moves into the planning stage the level of accuracy can be
successively refined.

Project Proposal
This is the end of the Initiation Process for the project as a whole. Your project should now
be defined. That is, you should have reached agreement with your key stakeholders about:

 the project objectives (time, cost and quality or functionality)

 the exact nature of the product of the project
 who will deliver it
 constraints, assumptions and preliminary risks

Turner lists the objectives of the Project Proposal (or Project Definition Report) as being to:

VERSION: 1.0, March 2018 | Week 2

© WELLS INTERNATIONAL COLLEGE 55
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
  provide sufficient definition, including costs and benefits, to allow the business to
commit resources to the next phase
 provide a basis for the next phase
 provide senior management with an overview of the project’s priority alongside
day-to-day operations and other projects
 communicate the project’s requirements through the business
 define the commitment of the business to the project (Turner 1993)

You are now in a position to prepare a Project Proposal (also known as a brief, definition or
charter). This document should contain the following information:
 Project Purpose
o Briefly describes why the project is being undertaken
 Background and Strategic Context
o Describes the background and context for the project, including how it
relates to the key strategic plans
 Priority and other related projects
 Project Objectives
o Particularly scope/quality/performance/cost/time objectives
 Broad Scope including key deliverables
o In this section you clearly define the logical boundaries of your project.
Scope statements are used to define what is within the boundaries of the
project and what is outside those boundaries.
o Constraints and Assumptions
 Project assumptions are knowledge about the project that is taken
as being true or correct for the purpose of project planning.
Assumptions are made to allow planning to proceed with limited
information about certain elements that are vital to the
management of the project. Assumptions must be tested prior to
finalising the Project Plan.
 Project constraints are known facts that will influence how the
project is planned and managed. A constraint is a given factor that
is outside of the project planner’s scope of control, which unless it
is lifted or otherwise removed, will force project actions to work
around it.
o Deliverables
 Project Governance
 Key Stakeholders
 Preliminary Schedule (estimated timeframe/milestones
 Preliminary resources and cost estimates
 Preliminary Risk Assessment
o Project risks are characteristics, circumstances or features of the project
environment that may have an adverse effect on the project or the quality
of the deliverables.

Project Planning
Good planning is at the heart of project success and the good news is that good planning is
a skill that can be learned.

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

56 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
You will be introduced to techniques and tools that project managers use for producing a
project plan that covers
 Scope
 Cost
 Quality
 Time
 Risk
 Procurement
 Human Resources
 Communications

VERSION: 1.0, March 2018 | Week 2

© WELLS INTERNATIONAL COLLEGE 57
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 Scope Management

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

58 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
Scope Definition
The following documents can help in defining the scope of a project:
 A quotation
 A request for tender or request for proposal
 A contract
All of the above documents must contain an exact description of the work to be done in the
project.
Usually, in the concept phase of the project, a short document called a Project Charter is
produced (sometimes called a project brief). The Project Charter gives a short definition of
the parameters of the project and gives it some official recognition.
The following is an example of a project charter:

VERSION: 1.0, March 2018 | Week 2

© WELLS INTERNATIONAL COLLEGE 59
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 The 'Comments' section is transcribed below:
"This project must be done within ten months at the absolute latest" Mike Zwack, CEO
"We are assuming that adequate staff will be available and committed to supporting this project.
Some work must be done after hours toavoid work disruptions, and overtime will be provided." Jeff
Johnson and Kim Nguyen, Information Technology department.
You may also produce a scope definition for use within your organisation (this is not usually
seen by the client).
This scope definition would include the following information:
1) items to be delivered - eg. a fully functional network, 6 computers, a feasibility
report, a user manual
2) services to be provided - eg. client support, maintenance
3) things not included - eg. the project does not include writing the text for the web
site
4) things being provided by the client - eg. the client will provide pictures of each
product, the client will find actors for the multimedia presentation
5) assumptions (eg. Site access, hours of work) - eg. the project price is based on no
weekend or night work
6) time frame for the project - eg. the project is to be completed by July 2006
7) total price to the client - eg. the total price we are charging the client is $45,79

Example
Scope Definition for a project to install a new network into an office complex:
1) Items to be delivered: 12 new desktop computers, 1 laser printer, 2 switches, 1
router, cat 6 utp network cable, IBM Server
2) Services to be provided: installation of all items, configuration and setup of all
hardware to customer's specification
3) Things not included: training, copying of existing data onto new hard drives
4) Things provided by the client: desks, storage cabinet for the server, patch cables
and wireless network hardware
5) Assumptions: no asbestos present in the work area, building can be accessed in
non-work hours
6) Time Frame: the project will take approximately 4 weeks, subject to the availability
of hardware
7) Total Price: The client will pay $45,000

Scope Control
 In order to achieve the project's objectives, you must produce exactly what is in
the project scope
 If you produce LESS than the scope, the client will not be satisfied
 If you produce MORE than the scope, it will probably cost you more money than
you budgeted and the project will be a financial failure
 We control scope by requiring that all scope changes are IN WRITING
 The scope change process could look something like the following flowchart:

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

60 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
Work Breakdown Structure
The WBS is the Project Manager's main tool for defining scope
The Work Breakdown Structure is probably the most important tool used by the Project
Manager.
A Work Breakdown Structure is a hierarchical representation of all of the work in a project.
The WBS defines the work involved in the project and therefore helps us define the scope
(what is included and what is not included).
But why produce a WBS?
A WBS serves as a framework around which to build the project schedule. It helps you move
from the top-level activity of the project … down through a set of simpler, smaller activities
designed to build the software product deliverable, until the activities become small enough
to manage well. It helps everyone understand the relationships of tasks and activities to
each other in an illustrated way. It helps ensure that all the work is represented and that no
work steps have been omitted. It also helps the project team divide the work to be done into
small, well-defined tasks and activities. Of course, the WBS also facilitates planning,
estimating, and scheduling, and it is a basis for monitoring the project and for historical
data collection.

(from Futrell, R. et al, 'Quality Software Project Management' (Prentice Hall, NJ USA, 2002,
p.237)
There are two ways of presenting the WBS:
1) Graphically. If your audience likes looking at diagrams and pictures (and most
people do), use this method.
2) As a list. Use standard outline numbering to lay out your phases and tasks. The
example below illustrates this:

VERSION: 1.0, March 2018 | Week 2

© WELLS INTERNATIONAL COLLEGE 61
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 There are two pathways to producing a WBS:
1) Bottom Up
Brainstorm a list of tasks, then group these tasks into summary tasks based on their
relationships to each other.
2) Top Down
Start with the 'project', break the work up into phases, then continue to break each
phase or task into more detailed tasks.

How to do a WBS
We now move onto the question of how to construct a WBS?
Firstly, you need to decide which approach you are going to use - bottom up or top down.

Bottom Up
1) List every task or activity that you can think of.
2) Group these activities together. There are a number of ways of doing this. If you are
delivering a product, you can think of the various components within the product.
For example, a web page can be thought of as text, HTML, style sheets, graphics

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

62 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 and other media and code. So if you are producing a bottom up WBS for a web
page, you might group your list of tasks using these components as the categories.
3) Alternatively, you can group your tasks using the generic project management
lifecycle - ie. Initialising, Planning, Executing and Finalising. If you choose this
approach, then any tasks relating to the actual building of the web page will
probably get placed under the Executing category.

Top Down
1) Start with two or three words that describe the project - eg. 'Website', 'Customer
Database'.
2) Think of this project as consisting of a number of groupings of tasks - initialising,
planning, executing and finalising.
3) Each one of these phases/groupings contains more tasks - for example, planning
contains the task 'write the project plan'.
4) Each task contains a number of activities - for example, 'write the project plan'
could consist of 'document the scope', 'do a risk management plan' and 'do a
budget' (this list is not meant to be exhaustive!).
5) You could break these tasks apart even more, if you needed to. For example,
'document the scope' could consist of 'write the scope statements', 'produce the
WBS' and 'write the scope management plan'.
When doing a top down WBS, project managers often ask 'How much is enough detail?'
Well, you can get ridiculous with task detail.

For example - purchase hardware could be broken down into:

 ring the computer shop
 get a quote
 walk to shop
 pick up box
 walk back
 unpack the stuff
 put the box in the bin
The collection of data and the reporting of data at this level would be a waste of time and
money. The principle is "Only break work down to the level at which you are willing and
able to measure".
Now you have decided which approach you will use (bottom up or top down), you have
some more decisions to make:
 Are you going to produce your WBS as a list or graphically? Some people don't
mind reading lists, but most people prefer to see a picture. That old saying must
have some credibility - "A picture paints a thousand words".
 Are you going to produce your WBS using computer software?
Something to think about!
Doing a WBS on a computer can be a great idea, if you have the software and the
knowledge of how to use it. If you don't have these things, getting them can cost a lot more
than the benefit you gain from producing a lovely computerised WBS.
Let's move on now to examine how you can produce your WBS.

VERSION: 1.0, March 2018 | Week 2

© WELLS INTERNATIONAL COLLEGE 63
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 Manually
The beauty of the WBS is that you can sketch it or, as some companies do, use a big piece
of card, pin it on the wall and then write your tasks on hundreds of removable 'post-it'®
notes. Using this method you can continuously shuffle, add and remove tasks until you are
happy with your structure. Another advantage of this method is that you can get members
of the project team working together, having fun.

Software
Microsoft Project is project management software that helps you plan and monitor
projects. It incorporates a number of commonly used project management methods and
tools such as the WBS, Gantt Chart and Critical Path.
You can read a more detailed overview of MS Project at:
[Link]
Micosoft Project will produce a WBS in list format. If you have the software, you can use
the 'gantt chart view' to produce your WBS. If you want to see the outline numbering turn
on numbering by selecting it in Tools-Options-View-Show Outline Number. This will show
you a hierarchically numbered list similar to the earlier example.
For a tutorial on MS Project go to:
[Link]

Project Cost Management

General Terms
Cost: a cost is something given up in exchange for something else. In this context, it refers
to money given in exchange for goods and services

Overview of processes
Estimation - done in concept phase - very rough, 20-25% error margin. However, most
decisions are done based on this cost
Cost Planning - done in the planning phase - consists of looking at the work breakdown
structure, determining the tasks that need to be done, determining the resources (both
people and materials) that need to be acquired then planning these costs. This is primarily
done using budgets - eg. Income/cost budget, time based budget, cash flow forecast
Cost Control - the methods we use to control costs so that we are not overspending - these
will be discussed later
Cost finalisation - the activities we do at the very end of the project - eg. Pay the bills,
collect the payments, dispose of assets, update the books/accounts, etc.

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

64 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
Project Quality Management
What is quality?
The International Organisation for Standardization (ISO) defines quality as:
"the degree to which a set of inherent characteristics fulfils requirements" (ISO9000:2000).
Other experts define quality based on:
 Conformance to requirements: The project's processes and products meet
written specifications.
 Fitness for use: A product can be used as it was intended.

Parameters of Quality
The following parameters apply particularly to products, but in some degree to services:
 Functionality is the degree to which a system performs its intended function.
 Features are the system's special characteristics that appeal to users.
 System outputs are the screens and reports the system generates (applies to
computer systems)
 Performance addresses how well a product or service performs the customer's
intended use.
 Reliability is the ability of a product or service to perform as expected under
normal conditions.
 Maintainability addresses the ease of performing maintenance on a product.
 Durability addresses how well the product lasts under normal operating
conditions

Processes
1) Quality planning: Identifying which quality standards are relevant to the project and
how to satisfy them.
2) Quality assurance: Periodically evaluating overall project performance to ensure
the project will satisfy the relevant quality standards.
3) Quality control: Monitoring specific project results to ensure that they comply with
the relevant quality standards.

Project Time Management

Processes
Activity Definition - this is done in the Work Breakdown Structure
Activity Sequencing - in which order do the tasks have to be done, which tasks are
dependent on other tasks
Activity Duration Estimating - over what period does each task get done
Schedule Development - producing the project schedule, often done with software such as
MS Project

VERSION: 1.0, March 2018 | Week 2

© WELLS INTERNATIONAL COLLEGE 65
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 Schedule Control - keeping track of how the project is progressing, comparing actual
progress with planned progress, responding to schedule problems

Risk Management
Risk is defined as any adverse event that may have a negative impact on our project

Risk Management Processes

 Risk identification - thinking about the things that MIGHT happen (see examples
above under 'Areas of risk'
 Risk Quantification - we evaluate and give a rating for:
o Impact: if this risk occurs and is the worst it could possibly be, what will be
the impact on our project? Usually we allocate a number in a range of say
1-10, 1 being the lowest and 10 being the highest.
o Likelihood: how likely is this risk? It's hard to be really accurate, however,
there will often be clues you can use to help you. For example, if your
building is in an earthquake zone, earthquake risk will receive a high
probability rating. Again, likelihood is allocated a number from a range of
numbers (eg. 1 for not very likely, 2 for likely, 3 for extremely likely)
 Risk Monitoring and Response- during the project the project manager
constantly assesses the risks and their likelihood of happening
o Question: How would you manage the risk of other work completed on
time?

Project Procurement Management

Procurement management, most commonly, deals with the nature, formation,
development and administration of contracts.
Contracts are used widely in public and private sector projects. You need to become
familiar with the basics of contract formation and administration if you are to effectively
function as a Project Manager

Contracts and contract law

A contract is essentially a promise.
As put by one author:
A contract is a legally binding arrangement in which one party agrees to do something in
exchange for another party agreeing to do something else (Steven Titmus, "77 Classic
Contract Mistakes", Prentice Hall, 2001, p.3)
Contract Law is a very complex topic. A full treatment of it is beyond the scope of this
resource. However, Project Managers need to know enough about contracts to form and
administer them. This doesn't mean that you have to know how to write a contract. In
many cases you will either use a standard contract or have a contract written by a legal
professional.

The Contracting Process

The contracting process can go down several pathways:

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

66 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
  Pathway 1: The work of the project is to be done by contractors
In this case, the PM is responsible for overseeing the work of the contractor. The
contractor often appoints its own internal Project Manager. Please remember
that the process will vary from project to project and between organisations.
Large Government contracts often use a more rigourous process because of the
higher amount of public scrutiny and accountability.
 Pathway 2: The project involves the formation and execution of contracts for
all or part of the work and/or for the procurement of resources needed for
the project
In this pathway, the work of the project is done by the project manager's
organisation, but some of the work involves the formation of contracts. Contracts
are formed between the PM's organisation and the customer and in many cases
with suppliers of materials and sometimes labour.

Project Human Resource Management

People are our most important asset" - your project cannot be completed without people
doing their jobs correctly and on time.
Managing human resources is one of the toughest challenges for the project manager.
People can be complex and our interactions with people are rarely straightforward. People
are also very diverse which can lead to conflict. These and other factors add to the
challenge of managing people.

Project Communications Management

Communications management is a new area that has recently become an integral part of
large projects. It is yet another area of expertise which you may choose to develop in order
to make yourself multi-skilled.

Project Communication Management Processes

Communications Planning
Determining the information and communications needs of the stakeholder, who needs the
information, when they need it and how it will be given to them.
Remember. Communication won't happen unless you make it happen and build it into the
schedule.
Questions to be answered:
1) How will pieces of information be collected and filed, so that everyone knows it is
there and can access it?
2) How do we ensure that the latest copy of anything is the one that is being used?
3) How will everyone know when new products have been chosen to be used and
where information about them is held?
4) Who is to be given particular types of information? Eg. Does every stakeholder
receive a copy of schedule updates?
5) Will there be templates for the project team to use? (Project reports, minutes,
memos and documents)
6) Is there a list of project acronyms and definitions?

VERSION: 1.0, March 2018 | Week 2

© WELLS INTERNATIONAL COLLEGE 67
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 7) Is someone responsible for creating, assembling and disseminating key project
information?
8) Do people know when this information is due?
9) Do people know when regular project meetings are to be held? And who is
supposed to attend?
10) Have you allowed time for review and approval of project documents?
11) Who needs to review draft documents? Is there a list of these people?
12) Where is documentation kept? Does everyone have access to it?
13) Who is responsible for keeping the project plans up to date?
14) How are new versions distributed? And to whom?

Information Distribution
Making information available to stakeholders in a timely manner. Need to include informal
as well as formal methods for information distribution and gathering. Informal methods can
gather more information than written forms as people find it easier to speak their concerns
rather than write them down. Oral communication also helps build stronger relationships
within the project.
Questions to be answered:
1) What is the best way to distribute project information?
2) Is it sufficient to send written reports for project information?
3) Are meetings alone effective ways of distributing project information?
4) Do we need to send information and have meetings to ensure that the information
is understood?

Performance Reporting
Collecting and disseminating performance information including status reports, progress
reports and forecasting.
 Status Reports. Where the project stands at a specific point in time. Where the
project stands in terms of scope, time and cost goals.
 Progress Reports. Describe achievements during a specific time period. May be
weekly or monthly. Sometimes changes if the activity is critical to the project
continuing to meet its deadlines.
 Project Forecasting. Predicts future project status and progress based on past
achievements. Status review meetings are used to highlight important
information and discuss project issues. Need to be managed carefully.

Administrative Closure
Generating, gathering and disseminating information to formalise phase or project
completion. Every phase requires closure. It verifies and documents the project results. It
also formalises sponsor or customer acceptance of the product (sign off).

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

68 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
Week 3

VERSION: 1.0, March 2018 |

© WELLS INTERNATIONAL COLLEGE 69
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 Quality Planning
Implies the ability to anticipate situations and prepare actions to bring about the desired
outcome.
The desired outcome is to SATISFY THE CLIENT'S EXPECTATIONS
This is done by:
 Selecting proper materials (eg. durable, conform to appropriate standards). Many
Australian Government Departments will only use 'Government Approved Suppliers'. This
gives them some assurance that a supplier meets certain minimum standards (see
information about Queensland Government Approved Suppliers as an example -
[Link]
 Training people in quality and its importance.
 Planning a process that ensures the appropriate outcome. Some of these processes
include:
o Control of documents - much of the project's data is kept in documents. Document
control is therefore critical to controlling the creating, editing and deletion of all
project documents. Read more about document control and how to do it at:
[Link]
o audits and inspections
o record keeping - keeping records of inspections, interviews, audits, meetings and
anything else you do in your project. These documents also need to be controlled
as detailed above.
o acceptance criteria and interview - at the beginning of a project, you talk to your
client and find out exactly what is required. This information forms the 'acceptance
criteria', ie. that things that must be done before the client will accept the project
outcomes. At the end of the project, you go through the project's results with the
client in order to determine or demonstrate that all of the acceptance criteria have
been met. The Tasmanian Government has an excellent set of resources for project
managers. Read some excellent background on acceptance testing
([Link]

Quality Objectives
Quality Objectives, like all objectives should be SMART objectives, that is, the objectives
should be:
 Specific
 Measurable
 Attainable
 Relevant
 Timely
According to the ISO 9000:2000 Standard [Clause 5.4.1]:
"Top Management shall ensure that Quality Objectives, including those needed to meet
requirements for product, are established at relevant levels within the organisation. The
quality objectives shall be measurable and consistent with the quality policy."

ISO 9000
IEEE ISO 9000 indicates that a quality management system and continual improvement of
the system must be supported by the collection of appropriate data, analysis of the data
and reporting the results.

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

70 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
In ISO 9000:2000, the definition of a Quality Objective is: "Something sought, or aimed for,
related to quality."
The key concept here is that - if you aim for something, you need to know if you achieved it
- therefore, the objectives should be measurable. Quality Objectives should be associated
with key elements of quality, such as fitness for use, performance, safety, reliability and
conformance to standards.

Examples of quality objectives

Quality objectives can be very specific or generalised - but they should always be
measurable!
Specific Objective: (sometimes known as the quality criteria)
To achieve a 95 percent confidence level that data displayed online is an accurate
representation of the current stock levels.
General Objective:
To upgrade the technology knowledge of all personnel through continuous improvement
training, it is common for quality objectives to be a general statement - but related to a
specific area.

ISO 9126
IEEE ISO 9126 is a software evaluation standard, it provides a listing of Software Quality
Characteristics and Attributes. The software quality characteristics are a useful starting
point when developing your quality objectives. The eight characteristic groups proposed in
ISO 9126 are:
Functionality. Characteristics relating to achievement of the basic purpose for
which the software is being engineered.

Reliability. Characteristics relating to the capability of software to maintain its level

of performance under stated conditions for a stated period of time.

Understandability. Characteristics relating to the effort needed for use and on the
individual assessment of such use, by a stated or implied set of users.

Efficiency. Characteristics related to the relationship between the level of

performance of the software and the amount of resources used, under stated
conditions.

Maintainability. Characteristics related to the effort needed to make modifications,

including corrections, improvements or adaptation of software to changes in the
environment, requirements and functional specifications.

Portability. Characteristics related to the ability to transfer the software from one
organisation or hardware or software environment to another.
Source: Software Engineering Body of Knowledge, p11-4

VERSION: 1.0, March 2018 | Week 3

© WELLS INTERNATIONAL COLLEGE 71
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 ISO 9126 as a reference for Quality Objectives
Referring to ISO 9126 is a good starting point when developing objectives. You may choose
one or more of the Software Characteristics as a base for your quality objectives.

Example

Example Quality
Characteristic Rationale
Objective

Reliability Where faults or unexpected inputs disable

Characteristics relating to the a module - the independence and de-
To develop de-coupled
capability of software to coupling of the module will enable
(independent) but
maintain its level of operation of critical business systems that
cohesive software
performance under stated are not dependent on the module. An
modules.
conditions for a stated period isolated fault should not cause a failure of
of time. the total system.

Understandability
Characteristics relating to the
Intuitive web based interfaces/icons
effort needed for use and on To build intuitive web
minimise user training and increase
the individual assessment of based interfaces.
usability.
such use, by a stated or
implied set of users.

Portability
Characteristics related to the To develop software
Software that is POSIX (Portable Operating
ability to transfer the software that will be operable in
System Interface) compliant has been
from one organisation or both Windows and Unix
requested by the client.
hardware or software environments.
environment to another.

Note: the rationale has been provided for the students understanding - usually the rationale
is not included with the objective.

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

72 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
Aligning Quality Policies, Objectives and Processes
Quality Objectives are not a stand-alone item; they should be incorporated into the
management, processes and even culture of an organisation.

Standards
That which is established by authority as a rule for the measure of quantity, extent, value,
or quality ([Link]
Andrew Tanenbaum, in his Computer Networks book, once said, "The nice thing about
standards is that there are so many of them to choose from". This is a reference to the fact
that competing standards become a source of confusion, division, obsolescence and
duplication of effort instead of an enhancement to the usefulness of products.
Organisations concerned in one way or another with computing standards include:
 IAB (RFC and STD)
 ISO
 ANSI
 DoD
 ECMA
 IEEE
 IETF
 OSF
 W3C
Discussing specific standards is outside the scope of this resource, however, a listing of
relevant standards has been provided.
Project documents and product specifications may specify adherence to nominated standards. It is
not important that extracts from the standards are copied and pasted into the documents, however
it is appropriate that the name of the standard(s) appear in the documents and that the nominated
standard(s) is relevant to the project or product.

Searching for information on standards

Some standards are proprietary, that is, the standard has been developed by a group or
organisation and it belongs to that group or organisation. In order to use or reference the
standard you must pay a fee. ISO and IEEE standards are proprietary standards. You will
only be able to access limited abstracts from their website.

Gaining Agreement
Determining quality objectives and standards is not a one-person task. Objectives and
standards should be agreed between the project team and the client. Objectives and
standards should be discussed and negotiated. When agreed, the objectives should be
documented and signed off.

Methods, Tools and Techniques

The Project Management Book Of Knowledge (PMBOK 2000) pages 98, 101 & 103 identify
several quality management tools and techniques. These include:

VERSION: 1.0, March 2018 | Week 3

© WELLS INTERNATIONAL COLLEGE 73
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
  Cost/benefit analysis
 Benchmarking
 Flow-charting
 Design of experiments
 Quality audits
 Inspection
 Control charts
 Pareto diagrams
 Statistical sampling
 Trend analysis
Source PMBOK (2000), Chapter 8. Project Management Book Of Knowledge (PMBOK 2000)
pages 98, 101 & 103

Making the tool/technique selection

No matter what technique or tool you choose, there will be some cost - the obvious cost is
labour cost.
Consider someone writing code; they cannot write new code and test somebody else's
code at the same time - so there is a cost involved in checking conformance to standards
and specifications. But what is the cost of rework if an error moves through to the next
phase of development without detection?

Five major costs related to quality

There are five major costs related to quality. These are:
 Prevention cost.
Planning and executing a project so it is error free (training, quality surveys of
suppliers and subcontractors).
 Appraisal cost.
Cost of evaluating the process and their outputs (inspection, testing,
maintenance of test equipment).
 Internal failure cost.
Cost of fixing errors before the customer receives the product (scrap, rework,
charges for late payment, premature failure).
 External failure cost.
Errors that go without being found (warranty, field service personnel training,
complaint handling).
 Measurement and test equipment.
Capital cost of equipment used to perform quality testing, appraisal.

Cost of Quality
Cost of Quality = cost of conformance + cost of non-conformance (the cost of quality to
produce a conforming product added to the cost of any products which do not conform).

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

74 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
In the following diagram for software development you will notice that there is not one test
or technique that will detect all errors and faults. The average detection effectiveness
ranges from 30% to 60%. But, importantly, cumulatively 93% to 100% of errors are
detected with the most common (modal) being close to 100%.

Source: Seattle Area Software Quality Assurance Group [Link]

Quality Criteria
Criteria: "A basis for comparison; a reference point against which other things can be
evaluated" ([Link]

VERSION: 1.0, March 2018 | Week 3

© WELLS INTERNATIONAL COLLEGE 75
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 Criteria: "A standard of judging; any approved or established rule or test, by which facts,
principles, opinions and conduct are tried in forming a correct judgment respecting them".
(Webster's Dictionary)
Quality Criteria are the specific elements or functions that will be selected, tested and
measured in order to confirm that the quality objectives have been met.
The Technical Specifications, Non-Functional and Functional Requirements (which may
already exist) form part of the quality criteria. These specifications and requirements may
be expanded once you complete your review of quality management.

ISO 9126
As discussed before, ISO 9126 (Software Quality Characteristics and Attributes), can be a
useful starting point when identifying quality objectives. Because quality criteria are subsets
of quality objectives it is worthwhile reviewing the ISO 9126 quality characteristics and
attributes when defining the quality criteria.
ISO 9126 as a reference for Quality Criteria, referring to ISO 9126 is a good starting point,
when developing criteria. You may choose one or more of the Software Characteristics as a
base for your quality criteria.

Example
Example
Characteristic Quality Rationale Quality Criteria
Objective

Reliability. Characteristics To develop Where faults or Failure of a software module

relating to the capability of de-coupled unexpected inputs will not cause a failure of the
software to maintain its (independent) disable a module - the total system
level of performance under software independence and de-
stated conditions for stated modules. coupling of the module Maintenance may be
period of time. will enable operation of conducted on one module
critical business systems without significant impact on
Fault tolerance. Ability to that are not dependent core business systems.
maintain a specified level of on the module. An
performance in cases of isolated fault should not
software faults or cause a failure of the
unexpected inputs. total system

Understandability. To build Intuitive web based Users are able to readily

Characteristics relating to intuitive web interfaces/icons minimise recognise and can easily
the effort needed for use based user training and interact with interface
and on the individual interfaces increase usability controls
assessment of such use, by All interface controls will
a stated or implied set of have relevant onscreen help
users. (examples: meaningful error
messages, hover over "quick
Operability. The ease of tips" etc.)
operation and control by
users.

Portability. Characteristics To develop Software that POSIX Software conforms to POSIX

related to the ability to software that (Portable Operating standards
transfer the software from will be System Interface)
one organisation or operable in compliant is required by Software operates in a Unix
hardware or software both environment

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

76 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
environment to another. Windows and the client.
Unix Software operates in a
Adaptability. The ability for environments. Windows environment.
its adaptation to different
specified environments.

Note: the rationale has been provided to help understanding - usually the rationale is not
included with the objective

Quality Requirements
General Manufacturing Vs Projects.
Quality Objectives and Quality Improvements go hand-in-hand. That is, many of the
objectives are based around improving quality. In order to improve quality you need to
know the current status of quality - you need to know your starting point! For a
manufacturer, identifying improvement in product quality is a relatively easy process -
simply compare quality in manufactured goods over time. On the other hand, it is not easy
to assess the quality of a product produced by a project, this is because projects are often
"one-off" and customised to the client's requirements.
To assess the quality of a product produced by a project, you need to know the targeted
destination. It is important to develop a project plan, project base line and product
specifications. Each of these documents should include quality objectives.

Updating project documentation

Planning for quality is an integral part of project planning. Quality is not something that is
inspected or tested at the end of a project. It should be a focus throughout all aspects of
the project. In a well-prepared project, the document called the "Quality Plan" could
effectively be used as the "Project Plan". Indeed the Quality Plan should be an integral part
of the Project Plan.

Project schedule
The project schedule should include tasks for quality assurance. Major checkpoints in the
project where key deliverables will be tested need to be clearly identified. Each process or
phase within the project must be structured to allow easy measurement of progress against
the specification.

Non-Functional Requirements
Once you have identified the quality objectives and quality criteria, it is prudent to update
project documents such as your Non-Functional Requirements in your Requirements
Documents.

Risk Management Plan

Risk is defined as any adverse event that may have a negative impact on our project

Areas of risk
Here are three areas of risk, you may be able to think of more:
 People - people may become sick or die or may work slowly or unproductively

VERSION: 1.0, March 2018 | Week 3

© WELLS INTERNATIONAL COLLEGE 77
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
  Distasters - fires, earthquakes, storms, floods
 Suppliers - may run out of stock or not provide the goods or services at the
correct time

Risk Management Processes

 Risk identification - thinking about the things that MIGHT happen (see examples
above under 'Areas of risk'
 Risk Quantification - we evaluate and give a rating for:
o Impact: if this risk occurs and is the worst it could possibly be, what will be
the impact on our project? Usually we allocate a number in a range of say
1-10, 1 being the lowest and 10 being the highest.
o Likelihood: how likely is this risk? It's hard to be really accurate, however,
there will often be clues you can use to help you. For example, if your
building is in an earthquake zone, earthquake risk will receive a high
probability rating. Again, likelihood is allocated a number from a range of
numbers (eg. 1 for not very likely, 2 for likely, 3 for extremely likely)
 Risk Monitoring and Response- during the project the project manager
constantly assesses the risks and their likelihood of happening
o Question: How would you manage the risk of other work completed on
time?

Risk Matrix - a risk management tool

Once risks have been identified, there are 3 courses of action:
1) Risk Avoidance- Eliminates the risk by eliminating the cause. Not all risks can be
eliminated.
2) Risk Acceptance- Accepts that it might happen, and prepares a contingency plan in
case it does.
3) Risk Mitigation- Reduces the impact of a risk by reducing the probability it will
happen.

Risk Event:

Probability of Risk Risk Rating Risk Score

Warning Signs

Contingency (before risk event)

Control Technique (after risk event)

Explanation of risk management matrix terms:

Risk Event
Description of risk

Probability of risk
1) Highly Unlikely- could happen but probably never will
2) Unlikely- could happen, but only rarely

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

78 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 3) Likely- could happen occasionally
4) Very Likely- could happen frequently

Risk Rating/ Severity

1) Low- risk acceptable
2) Possible- attention required
3) Medium- correction required
4) High- substantial attention and correction required

Risk Score
Probability of Risk x Risk Rating

Warning Signs
Precursor events - things that tell you that this risk may be about to occur

Control Technique
Action taken if risk event occurs

Contingency
Measures put into place to prevent the risk event from occurring

Example
The following table shows an analysis of a common project risk - building fire

Risk Event: Fire in the project office

Probability of Risk Risk Rating Risk Score

3 - could happen occasionally 4 - High - substantial loss of 12 out of a possible 16
project deliverables and
planning documents

Warning Signs
Smoke, flames (by then it is just about too late) or monitored alarm is triggered if an alarm is
installed.

Contingency (before risk event)

Smoke detectors and alarms (monitored), sprinkler system, fire hoses, fire extinguishers.

Control Technique (after risk event)

Call fire brigade, fight fire, evacuate building, move to back-up office and reinstate all data and
systems.

VERSION: 1.0, March 2018 | Week 3

© WELLS INTERNATIONAL COLLEGE 79
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 Week 4

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

80 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
Project schedule
Activity Sequencing
 DEFINITION: Duration: the period of time over which a task is done
 DEFINITION: Effort/Work: the number of hours of work required to complete a
task

Example
The task 'Research flat screen monitors for the Transadelaide Multimedia System' may have
duration of five working days, but the effort that is required is only five hours. How is this
possible? Well, a person may work on it for one hour a day for five days. This is quite
normal as your staff will often have a number of tasks to work on each day and so cannot
spend their whole day on one task.
 The WBS does not show the order in which the tasks are to be done
 The WBS does not show the duration or start or finish dates of each task
 This is done in the project schedule

Activity Duration Estimating

After you have done your WBS, take each task that is not a summary task and estimate its
duration in minutes, hours, days, weeks, months, years or whatever

Example: Task Number Task Name Duration

1.1 Research Flat Screen Monitors one day
Then ask, 'Does this task depend on other tasks?'.

Example
Task 1: Research Flat Screen Monitors
Task 2: Present a brief report on recommended monitors
Task 2 cannot start until you have done task 1 - this is called a task dependancy
There are a number of different kinds of task dependancies. For more information, read the
section on Gantt Charts in this resource

You should also consider the following when estimating duration:

You may like to build in some extra duration as a form of risk management. Such extra time
is called 'contingency' time

Example
You may estimate that installing network cables is about 40 hours work and can be done
over five working days. However, you decide to estimate seven working days and 45 hours
to allow for unforseen problems that may arise such as cable not being available, workers
being sick, etc.

VERSION: 1.0, March 2018 | Week 4

© WELLS INTERNATIONAL COLLEGE 81
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 Lag and Lead time - time that gets added onto the end of a task - it is 'dead' time

Example
You may not be able to walk on fresh concrete before it has dried, so:
Pour concrete Duration five days
Walk on concrete Duration one day (predecessor 'pour concrete', finish to start
dependancy with three days lag time)

Lead time is 'dead' time that happens before a task starts

Read more about lag and lead time in Microsoft Project -
[Link]

Gantt Chart
It's a funny name but one that sticks with you. Like a lot of things, it was named after the
person that first invented it - Henry Gantt. Read the following for a bit of history on Henry
Gantt and the Gantt chart:
Henry Laurence Gantt (1861-1919) was a mechanical engineer, management
consultant and industry advisor. Henry Laurence Gantt developed Gantt charts in
the second decade of the 20th century. Gantt charts were used as a visual tool to
show scheduled and actual progress of projects. Accepted as a commonplace
project management tool today, it was an innovation of world-wide importance in
the 1920s. Gantt charts were used on large construction projects like the Hoover
Dam started in 1931 and the interstate highway network started in 1956 (Source:
[Link]
But why bother?
A Gantt Chart is:
 A useful tool for planning and scheduling projects
 A tool that enables you to assess how long a project will take
 A tool that helps manage dependencies between tasks
 A tool that helps you monitor progress once the project is underway
 A modeling tool to help you get your project back on schedule

(based on 'Gantt Charts' online at: [Link]

How to Produce a Gantt Chart

Before you produce a Gantt chart, you need:
1. A detailed list of tasks (from your Work Breakdown Structure)
2. The start and finish dates of each task
3. Any constraints on these tasks. A constraint is a requirement for when a task must start
or finish. The following are examples of constraints (note: this information is taken from

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

82 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 the MS Project Help File and so is, to a certain degree, specific to that application. It
does however show the basic meaning of each type of constraint):
 As Late As Possible. With this flexible constraint, Microsoft Project schedules
the latest possible start and finish dates for the task, given other scheduling
parameters. This is the default constraint for new tasks for a project scheduled
from the finish date.
 As Soon As Possible. With this flexible constraint, Microsoft Project schedules
the earliest possible start and finish dates for the task, given other scheduling
parameters. No additional date restrictions are put on the task. This is the default
constraint for new tasks for a project scheduled from the start date.
 Finish No Earlier Than. This moderate constraint indicates the earliest possible
date that this task can be completed. It cannot finish any time before the
specified date.
 Finish No Later Than. This moderate constraint indicates the latest possible
date that this task can be completed. It can be finished on or before the specified
date.
 Must Finish On. This inflexible constraint indicates the exact date on which a
task must finish. Other scheduling parameters such as task dependencies, lead or
lag time, resource leveling, and delay become secondary to this requirement.
 Must Start On. This inflexible constraint indicates the exact date on which a task
must begin. Other scheduling parameters such as task dependencies, lead or lag
time, resource leveling, and delay become secondary to this requirement.
 Start No Earlier Than. This moderate constraint indicates the earliest possible
date that this task can begin. It cannot start any time before the specified date.
 Start No Later Than. This moderate constraint indicates the latest possible date
that this task can begin. It can start on or before the specified date. See
[Link] - part 2 of lesson 1 (the
section is entitled 'links') to read about task constraints.

4. Any relationships between the tasks. For example, you have to finish a web page before
you can upload it. In that instance, the relationship is called a Start-Finish relationship.
There are other types of relationships. You can read about these in the following table
from the Microsoft Office Assistance Website ([Link]

Task Example Description

dependency

Finish-to- Task (B) cannot start until task (A) finishes. For
start (FS) example, if you have two tasks, "Construct
fence" and "Paint fence," "Paint fence" can't
start until "Construct fence" finishes. This is the
most common type of dependency.

VERSION: 1.0, March 2018 | Week 4

© WELLS INTERNATIONAL COLLEGE 83
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 Start-to- Task (B) cannot start until task (A) starts. For
start (SS) example, if you have two tasks, "Pour
foundation" and "Level concrete," "Level
concrete" can't begin until "Pour foundation"
begins.

Finish-to- Task (B) cannot finish until task (A) finishes. For
finish (FF) example, if you have two tasks, "Add wiring"
and "Inspect electrical," "Inspect electrical"
can't finish until "Add wiring" finishes.

Start-to- Task (B) cannot finish until task (A) starts. This
finish (SF) dependency type can be used for just-in-time
scheduling up to a milestone or the project
finish date to minimize the risk of a task
finishing late if its dependent tasks slip.
If a related task needs to finish before the
milestone or project finish date, but it doesn't
matter exactly when and you don't want a late
finish to affect the just-in-time task, you can
create an SF dependency between the task you
want scheduled just in time (the predecessor)
and its related task (the successor). Then if you
update progress on the successor task, it won't
affect the scheduled dates of the predecessor
task.

Interpretation of a Gantt Chart

Before we go on to examine how to produce a Gantt chart, it is helpful to see some
examples, and a little about how to interpret the chart.
Look at the following example (example 1), found on
[Link]
(if you want to see more examples, this is a great site!)

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

84 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
The beauty of the Gantt chart is its simplicity. The horizontal axis always represents the
time. The vertical axis always represents the tasks. The horizontal bars show the duration of
each task. The start and end of each bar (usually marked off with a special shape, in this
case a circle) shows the start and end time/date of the task.
In this more complex example, you can see extra information on the chart.

Notice that we can place tracking information on the chart by

putting a line inside the task bar to indicate progress on a task.
We can also put text next to the bars so that we can see who
is assigned to the various tasks. We can also use lines between
tasks to show task dependencies.
Now let's move on and discuss how to do it.

Manual Method for Producing a Gantt Chart

You could draw a Gantt chart if you wanted to. All you need is a pencil, ruler and some
graph paper. You would construct your chart like the one in the diagram:

Drawing it by hand is acceptable, but it becomes messy if

you want to change it. This is the big advantage of using
software to draw your chart.

VERSION: 1.0, March 2018 | Week 4

© WELLS INTERNATIONAL COLLEGE 85
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 Using MS Project
MS Project gives you a graphical interface to use in drawing Gantt charts. If you are able to
get the MS Project software, you should try the following tutorial:
[Link]

Schedule Development and Control

Critical Path Analysis
See this resource's section on critical path analysis

Project tracking
After you have entered all your project plan data into a software programme such as MS
Project, you do the following:
 Create a baseline - this is a snapshot of the schedule against which you will
measure actual progress
 Enter actual data as it comes in (eg. A task's duration may have been one day in
the plan but it took two days)
 Compare actual versus planned progress
Respond to variations by:
1. 'Crashing' the schedule - ie. Shortening the times, working overtime, longer hours,
etc.
2. Revising the schedule
3. Multitasking - do some things together - break traditional 'finish to start'
dependancies

Critical Path
The critical path consists of all of the tasks that cannot be started late if the project is to
finish on time. These tasks are said to have no 'float' (float is the difference between the
earliest start time and the latest start time).

Producing the critical path

It is not really correct to say that you 'produce' the critical path. We can analyse a series of
tasks to show or highlight the critical path.

Manually
If you want to analyse the critical path manually you can, using a special diagram called a
network diagram. The key data in this process are the task durations and task
dependencies.
You should be aware though that it is a rather tricky and long process. We have provided a
link that you can visit to learn how to do it-

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

86 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
[Link]

MS Project
Most project managers use software to analyse the critical path. The most widely used
software tool is probably MS Project.
Showing the critical path in MS Project is simple. Follow these steps:
1. On the View menu, click 'Gantt Chart'
2. Click 'Gantt Chart Wizard'
3. Follow the wizard instructions to format critical path tasks
The critical tasks will be shown in red (this is the default setting in MS Project).

VERSION: 1.0, March 2018 | Week 4

© WELLS INTERNATIONAL COLLEGE 87
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 Week 5

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

88 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
Financial Management Systems
When we think of financial management, we think of MONEY. But we should also think of
planning what we are going to get and what we are going to spend, and making sure we
have enough money to pay our bills when they are due.
Reflect: what sort of financial manager are you? Do you have a budget? Do you plan ahead
so that you will have enough to pay your bills when they are due?
Financial management within a project has two purposes:
1. To ensure that the project meets its approved budget
2. To enable reports to be generated

Financial management systems vary, depending on the organisation, from numbers written
in a ledger book to large mainframe based financial control systems. The elements of these
systems are always the same:
1. Resource Planning. Once you know the scope of a project, you must determine
what resources are needed to complete the work.
2. Cost Estimating & Budgeting. Estimates are made about the cost of each task,
based on the amount of the work for the task and the cost of the resource assigned
to it.
3. Cost Control. The methods used to monitor and control project costs to ensure that
the budget is not exceeded.
We will focus here on budgeting and cost control as the more important elements of this
process.

Budgets
A budget is:
 An estimate of expenses and income
 A project planning tool
 A means of comparing actual project performance against a plan

Budgets and Estimating

In order to develop a budget, estimates must be made. These are made on the basis of the
projected cost of the resource assigned to a task.
The main methods of estimating are:
1. Analogous. This is a way of estimating costs based on the similarity of the current
project to other projects you have done. By using this method, you arrive at a
'rough order of magnitude' estimate. This method can be quite inaccurate and is
usually only used in the very early stages of a project when determining feasibility.
2. Bottom Up. This is a method of estimating which is done after you have produced
your WBS. By examining the cost of each task in the WBS we can arrive at a total
cost for the project. Each task can be estimated more accurately because it is only a
small segment of work. Project Managers can get expert advice from experienced
employees about how long tasks will take. They can also use standard 'unit' costs.

VERSION: 1.0, March 2018 | Week 5

© WELLS INTERNATIONAL COLLEGE 89
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 Types of budgets and their uses
1. Income and Expense Budget
This is the most commonly used (and simple) kind of budget. It consists of the details and
amounts of all expenses and income for the project.
Producing a budget helps you to plan for your project's financial success. It enables you to
see if you are going to spend more than you receive. It enables you to foresee exactly what
tasks will cost.
BUT: It is not 'prophetic' - a budget is just an estimate of what will happen in the future.
That's why, once the project starts, we collect data on what things have ACTUALLY cost. We
can then compare this to our budget's predictions.
Like somebody once said: "If you are failing to plan, then you are probably planning to fail".
Your budget is a plan and without it, you have no idea if your expenses are too high or too
low.

What goes into a budget?

A detailed budget is made up of estimates of:
 Income - payments from your client, government grants or internal funding from
your organisation or any other income specific to your project.
 Expenses - money you have to pay out. These fall into a number of categories:
o Direct labour costs. When you have completed your WBS, you assign
resources (people and materials) to each task. You can then deduce the
cost of each task.
o Labour on-costs. The costs associated with employing people. Costs to
consider here are Workcover, Superannuation, Sick, Annual and Long
Service Leave, Leave Loading and Payroll Tax. Often labour on-costs add
30% to your wages bill.
o Overheads. The expenses you have to pay to keep your business running.
For example, rent, electricity, gas, telephone, internet, web hosting,
insurance, accountants fees, legal fees, business and company registration
fees.
o Direct materials. The physical things you need to build the product. This
could include special graphics or templates you procure for a web project.

2. Cash Budget
A cash budget is different to an income and expense budget.
An income and expense budget only lists the expenses and income for the whole project, it
does not tell us WHEN the expenses must be paid and WHEN the income will be received.
So, we might predict that our project will make a profit, but then run out of money in the
middle of it. This is a common business dilemma - running out of cash!
The way we prevent this crisis is by using our income and expense budget to produce a
CASH FLOW FORECAST (a fancy name for a cash budget).
To produce a cash flow forecast, you break the duration of your project into periods of
time, 1 week or 1 month for example. Then, for each of these periods you list the money
you will receive and the money you will pay out in expenses. If your expenses are more

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

90 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
than your income for that period, then you have a problem. You will need to take note of
some of the ideas from the section on 'Cash Flow Management'.
Look at this example of a cash flow forecast. Notice that some extra information has been
included:
1. A 'carried forward' cell for each month. Realistically, you try to have some cash in
the bank to see you through difficult times. In this example, we start with $5,500 in
the bank.
2. A 'loans taken' cell for each month. Notice in this example that by month 2, the
cash flow is in trouble. What can be done about this? Take a short term loan of
$25,000 to help pay for expenses until partial payments (these are called progress
payments) from the customers become available.
Take some time to examine the example cash flow forecast and budget.

Financial Baselines
A baseline is a snapshot of the project budget. When we have finished refining our budget
in the planning phase, we create a baseline against which we compare our actual costs.

Cost Control
A budget gives you a future prediction about your income and expenses. It is also a plan for
how much you are going to spend and on what.
But it is no good just having a plan, you have to DO YOUR PLAN.
Once the project is going along nicely, you use your budget to control expenses. This means
that you have to find out how much tasks and materials are actually costing and constantly
compare this to your budget. This is called 'MANAGEMENT'. If you get to wear the badge
'PROJECT MANAGER', then cost control will probably be part of your responsibility. You will
also be held ACCOUNTABLE for your budget.
So how do we control costs?

Cost Control Measures

 Cost Change Control. If anyone proposes a change in your agreed budget
baseline, don't just say 'Yes' blithely and hope that everything will be alright. Ask
for the change in writing, evaluate the change, do a deep evaluation of how
much the change will cost you and determine if you need to charge your client
extra or find extra funding from somewhere. Many projects fail simply because
the project just keeps getting bigger and bigger and nobody notices.
 Cash Flow Management. Use a cheque book for all your major expenses, use a
vouchered petty cash system for small expenses. Write down all your expenses
and regularly review them against your cash budget. Try and get your customer
to pay on time (consider offering discounts for early payment). Negotiate
extended accounts with your suppliers. Have an overdraft facility arranged with
your Bank so you can borrow easily if you need to.
 Cost Reporting. You should hold a regular project meeting with your internal
team and review actual costs against your budget. You can use your budget and
add 'actual' and 'variance' columns to each item. Graphics are excellent as well

VERSION: 1.0, March 2018 | Week 5

© WELLS INTERNATIONAL COLLEGE 91
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 and are quickly understood by stakeholders, like the example below (this is from
the spreadsheet example Project Budget and Cashflow [Link] that you have
been examining).

 Dealing with variance. Detecting, analysing and correcting - once you notice
variance occurring in your budget you should correct it immediately by:
o Amending your budget
o Finding cheaper materials or labour
o Eliminating wasteful work practices (or workers!)

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

92 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
Week 6

VERSION: 1.0, March 2018 |

© WELLS INTERNATIONAL COLLEGE 93
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 Team Development & Management
Building individual and group skills to enhance project performance (Not only technical but
also communication skills).

 Training - sometimes this is required before a person joins the team, sometimes
during the project a training need is identified.
 Team Building Activities - Sometimes the beginning of a project is a team building
session. Looks at personality types and areas where problems may be encountered
simply because people are different. Sometimes these are physical activities such
as abseiling to encourage development of team skills to achieve end goals.
 Motivations - Rewards and Recognitions, the project manager needs to recognise
and reward extra effort beyond the call of duty.
 Power - If the project manager relies too heavily on using authority, money or
penalty to influence people the project is likely to fail.

Tools and Methods

Work Breakdown Structure
The primary document that provides input into the HR Planning process is the Work
Breakdown Structure
The process you follow is:
1. Consult the list of tasks in the WBS.
2. Identify the skills needed to complete each task.
3. Group these skills into 'jobs' or 'roles'.
4. Write a simple job description for each 'job' or 'role'.
5. If you don't have existing staff with the correct skills or blend of skills, then you will
have to acquire them. This can done in a number of ways:
 Train existing staff (update skills, upgrade skills)
 Hire new staff - from an agency, or do it yourself (advertise, interview, select
and engage)

MS Project and Human Resources

MS Project, like any project management tool, contains some functions that will assist you
with human resource management. These are:
1. Resource Creation, costing and allocation
2. Resource customization - individual working times
3. Resource workload management (Project shows when you have given a resource
too much work and also allows you to 'level' resource workloads)
4. Resource Reports - eg. 'Who Does What' and 'To Do List' reports

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

94 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
Team management
Team skills
If you are working with or managing a team or a group of stakeholders, team management
skills are essential. These skills are best acquired experientially through workshops and
practice. Relevant Learning & Development Program workshops include:
 Fostering Teamwork
 Building Productive Relationships
 Negotiation Skills

Roles and Responsibilities

Definitions of the roles and responsibilities for a project should occur during the initiation
and planning phases. As roles and responsibilities are likely to change during the lifecycle of
the project, it is really important that those responsibilities are communicated continuously
during the Implementation phase.
Remember to spend time during Implementation with individual project personnel to make
sure they are clear about the responsibilities and have the required information and skill to
carry out the work. It is the Project Manager’s responsibility to:

 Identify the skills required for each part of the project

 Locate appropriate project staff
 Arrange for training if necessary
 Keep staff up to date with regard to any changes
 Look after the morale of the project staff
 Identify and resolve problems and conflicts

Tips for Effective Team Management

 Create an environment of trust, good relationships, respect
 Encourage consensus decisions-making, good performance and commitment to
client satisfaction
 Obtain input of project staff to the performance review of staff they interact with
in a significant way, as appropriate
 Improve team performance through team-building activities
 Reward and recognise good performance including team work
 Co-locate team members, if appropriate
 Provide training as required.

VERSION: 1.0, March 2018 | Week 6

© WELLS INTERNATIONAL COLLEGE 95
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 Week 7

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

96 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
Execute and manage the project
Integrate Project Activities
As you look at each knowledge area, focus particularly on the activities in each area that are
done during project implementation. The following table will help you.

Relationships Among Project Management Process Groups and Knowledge Areas

KNOWLEDGE AREA

INITIATING PLANNING EXECUTING CONTROLLIN CLOSING

G

Integration Project plan Project plan Integrated

development execution change
control

Scope Initiating Scope planning Scope

Scope definition verification
Scope change
control

Time Activity Schedule

definition control
Activity
sequencing
Activity duration
estimating
Schedule
development

Cost Resource Cost control

planning
Cost estimating
Cost budgeting

Quality Quality planning Quality Quality

assurance control

Human Organisational Team

Resources planning development
Staff acquisition

Communica Communication Information Performance Administrativ

tions s planning distribution reporting e closure

Risk Risk Risk

management monitoring
planning and control
Risk
identification
Qualitative risk
analysis

VERSION: 1.0, March 2018 | Week 7

© WELLS INTERNATIONAL COLLEGE 97
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 Quantitive risk
analysis
Risk response
planning

Procuremen Procurement Solicitation Contract

t planning Source closeout
Solicitation selection
planning Contract
administratio
n

The following diagram shows the relationship of these areas to each other:

Source: Schwalbe, K., Information Technology Project Management

Notice that Project Integration Management is the 'backbone' of the other 8 areas.
This is because project integration management is the process of linking the other functions
so that they are not going on exclusively from each other.

Example
You are working on a project for a client who wants a database-driven website. The client
asks you to install and configure a discussion forum. This work was not part of your original
agreement and is therefore an increase in the scope of the work. You should have a process
of formally changing the scope. This should involve the following steps:
1. Put the change request in writing
2. Evaluate the request in relation to its effect on the schedule, budget and quality of
the work. Examples of Evaluation Questions to be asked are:
 Will this change cause the project to take longer?
 Will it cost you more?
 Do you need to charge the client? If so, how much?
3. Decide if you want to make the change or not
4. Communicate this to the client

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

98 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 5. Update the relevant parts of the project plan (eg. budget, scope, schedule, human
resource plan)
6. Inform all stakeholders of the change

Provide Leadership and Development

A project manager should not be behind the project, pushing it along, but out in front of it,
leading it towards success.

Characteristics of leaders
There are many books and articles available on this subjects, all of which present varying
lists of qualities found in good leaders. However, here are a few common ones:
 knowledgeable about the area of work
 able to use contemporary management methods and tools
 confident but not arrogant
 interested in people
 caring
 empathetic
 goal oriented
 mental toughness and resilience
 likes to have fun
 respectful of individual differences
 able to admit mistakes and take responsibility for own actions
Browse the following web pages and make your own list:
 [Link] - based on sports psychology
 [Link]

Leadership Practices
Here are some things you can do to provide leadership to your project:
1. Be proactive - don't wait for problems to 'blow up'. Be alert for problems and deal
with them before they become serious.
2. Provide vision, goals and values - have a vision for the project, believe in its
objectives and be enthusiatic about it. Help your team define its goals and the
values by which it operates (eg. hard-working, fun loving, professional).
3. Communicate - be open and honest, communicate with integrity, communicate
regularly and by a number of channels. Pass on information to those who need to
know.
4. Be discrete - if you are having a bad day, don't let everybody know. If somebody
takes you into their confidence, don't break their trust.
5. Be available to people - open your office door, receive enquiries with professional
courtesy and respect, treat your team as your fellow-workers, not your subjects!
6. Provide development to your staff - recognise their skills, experience, knowledge
and also their desires and directions. Where possible, provide training and
opportunities for professional experience so that people that want to develop have
ample opportunity.

VERSION: 1.0, March 2018 | Week 7

© WELLS INTERNATIONAL COLLEGE 99
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 7. Monitor the well-being of your team. Watch for signs of stress and over-work.
There are thousands of articles available on this subject. Please take the time to
read about the signs of stress and what can trigger stress in the following sites:
 [Link]
 [Link]
 [Link]

Manage Stakeholders
A stakeholder is any person, group or organisation who:
 Has an impact on the project
 Is affected by the project
Stakeholders can be your greatest allies or your greatest adversaries. Good management is
therefore a key in keeping them as allies so that the project is not hindered.
In the first section of this resource you learned about how to plan for communication (see
the manage communication section)
Your communication plan should include communication and consultation with all the
relevant stakeholders
Stakeholders could be (this is not an exhaustive list):
 shareholders
 executive management
 board of directors
 users of the product or service you are producing
 government - councils, state or federal government
 the community/general public
 suppliers of goods or services
 unions or professional organisations
 other project managers
 your project staff
You could use a table like this one to help you to identify and analyse stakeholders:

Stakeholder Contact Notes Impact on Project Affected by the

(1 = Low, 2 = Medium, project
3 = High, 4 = Critical) (1 = Not affected, 2 =
some affect, 3 =
significantly affected,
4 = severely affected)

Managing ceo@[Link]. prefers email 4 4

Director of au contact
the
Company

Aboriginal kaurna@native. must consult 4 2

Groups [Link] as project is
near sacred
sites

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

100 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
Resolve Disputes
What can be disputed? Just about anything…
a) Scope
b) Extras
c) Schedule
d) Standard of the work/product
e) Price
"A contract is performed or completed when its satisfactory discharge leaves no grounds
for dispute". (UNE Dip. Project Management Course Notes, Module 8, page 38)
What can cause non-performance?
a) Frustration. This means that the contract is, for some reason, prevented from
continuing. This could be for reasons beyond the control of the parties concerned.
b) Breach. When the 'promise' or 'agreement' is not kept.
c) Disputed Fulfilment. One of the parties (often the one receiving the benefit of the
work done under the contract) believes that the other has not completely fulfilled
their end of the deal.
So, what can you do about it? You could…

a) Negotiate with the other party. If you find yourself in a contract dispute, try
meeting with the other party to negotiate. Negotiation means a 'win win', ie. both
parties win. In a client-supplier situation where a supply contract has been
breached, the ideal is for the contract to be re-established, perhaps in a modified
form. If the contract is terminated and legal damages are sought, the supplier loses
money and the customer is denied the services or goods that would have been
provided.
Further Reading: 'How to Negotiate' ([Link]
b) Litigate. Take the other party to court. The court may or may not rule in your
favour and the process can take several years and cost many thousands of dollars.
A civil court may award 'damages in tort'. This is compensation paid to restore the
parties to exactly the same position in which they would have been if the contract
had not been entered into.
c) Use a mediator. A mediator is a neutral person that acts as a 'go between' in a
dispute. The mediator helps to clarify the positions and goals of each party.

Negotiate Change Proposals

If you have entered into a contract with someone and your agreement is in writing, you
may both wish to alter the agreement. Perhaps the customer wants more work done and
so wants to extend the contract.
Contracts can be altered, but only when ALL PARTIES AGREE.
Contract Changes are usually in the form of changes in the project scope and/or budget.
Other elements that often change are the schedule and quality standards.
They can come from the client or from the project team. This is because a contract is a two
way agreement. So, the desire for change to the original agreement can come from either
party.

VERSION: 1.0, March 2018 | Week 7

© WELLS INTERNATIONAL COLLEGE 101
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 In either case, the process is essentially the same:
1. The need for change is identified.
2. A contract variation request is sent to either the project manager or client
(depending on who is initiating the request).
3. The contract change is evaluated in terms of scope, cost, time and quality. If the
change is accepted, will the price rise? If so, then by how much? Will the change
cause a change in the project schedule? Are we able to do the work (ie. Do we have
the capability?), is the requested work technically feasible?
4. If the party receiving the variation request agrees to the change, a contract
variation is prepared. This documents the changes in full and becomes part of the
contract between the parties.
5. Both parties must sign the variation - this demonstrates that everyone has agreed.
6. The variation becomes part of the agreement between the parties.

Managing Project Integration

There are many possibilities for how a project will progress and what documents will be
produced. This depends on where you are working and to what extent you or your
organisation apply project management methodologies and tools. If you are running a web
design business for example, your projects would probably follow the pathway listed
below:
1. Client requests quote or proposal
2. Quote or proposal is produced
3. Client accepts quote/proposal
4. Detailed design and plans drawn up
5. Client accepts detailed design
6. Development work is done
7. Website is tested and accepted by client (user acceptance testing)
8. Project is signed off
9. A finalisation letter and account is sent to the client

Integrate Project Outcomes

The eight main project management areas are:
1. Scope Management
2. Time Management
3. Cost Management
4. Quality Management
5. Human Resource Management
6. Communication Management
7. Procurement Management
8. Risk Management
The following diagram shows the relationship of these areas to each other:

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

102 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
Source: Schwalbe, K., Information Technology Project Management

Consult with Stakeholders

Consultation involves communicating with people and taking their thoughts and feelings
into account. During your project you will be required to communicate and consult with a
wide variety of people. If you choose not to do this, you may find that people will not
cooperate with you and they may even attempt to sabotage the project! It may also mean
that the finished product does not meet all of the required quality standards, which could
render it unusable.
REFLECT: Do you think that people believe they have the right to be consulted regarding
workplace decisions? Is this belief stronger now than in the past, say 50 years ago? Does
the public expect to be consulted regarding public sector projects? Why do you think this is
so?

How to consult
Provide information to your stakeholders. If you don't feed them information, they may
become suspicious and end up opposing your project.
List some different ways you could provide information to project stakeholders.
Compare them with this list:
1. Project Newsletter (printed)
2. Project E-Zine (emailed)
3. Project Website
4. Regular and Ad Hoc Project Team Meetings
5. Open Forums to discuss project issues
6. Special meetings with relevant stakeholder/s to discuss particular issues
Consultation goes a little further, you need to set up a 2-way communication, so that
people can provide information back to you regarding project decisions. You then need to
have regard to that information.
Consider the following if you want to effectively consult with people:
1. Be inclusive in your consultation - be careful not to leave key people out
2. Make people aware of the consultation process
3. Allow people a reasonable amount of time to consider all of the issues
4. Make the process transparent- be prepared to show how you have had regard to all
of the input gathered

VERSION: 1.0, March 2018 | Week 7

© WELLS INTERNATIONAL COLLEGE 103
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 The Victorian Local Government Consultation and Engagement Website lists seven
principles of effective consultation:
 Focus
 Inclusiveness, accessibility and diversity
 Provision of information
 Timing
 Responsiveness and feedback
 Evaluation
 Reporting
(source: Victorian Local Government Consultation and Engagement - online at:
[Link]

Review and Amend Plans and Contracts

Contract Changes are usually in the form of changes in the project scope and/or budget.
Other elements that often change are the schedule and quality standards.
They can come from the client or from the project team. This is because a contract is a two
way agreement. So, the desire for change to the original agreement can come from either
party.
In either case, the process is essentially the same:
1. The need for change is identified.
2. A contract variation request is sent to either the project manager or client
(depending on who is initiating the request).
3. The contract change is evaluated in terms of scope, cost, time and quality. If the
change is accepted, will the price rise? If so, then by how much? Will the change
cause a change in the project schedule? Are we able to do the work (ie. Do we have
the capability?), is the requested work technically feasible?
4. If the party receiving the variation request agrees to the change, a contract
variation is prepared. This documents the changes in full and becomes part of the
contract between the parties.
5. Both parties must sign the variation - this demonstrates that everyone has agreed.
6. The variation becomes part of the agreement between the parties.

Monitor Contracts
In this section we will discuss contract performance monitoring and reporting. We do this
on the premise of 'As the contract goes, so goes the project'. In other words, the success of
many projects depends upon the successful execution of the associated contracts. So it is
critical that the project manager monitors the performance of the contract.

Contract Performance Monitoring

This is commonly done by using milestones and performance reviews.

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

104 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 a. Milestones

A milestone is essentially a marker. It marks progress and tells you that you have
arrived somewhere or accomplished an objective.

In contract management, a milestone is a marker signifying that certain work has

been accomplished. These 'markers' are often accompanied by a review of the
work and payment to the contractor (subject to the work being satisfactory).

Milestones are usually written into the contract. They have the following benefits:

1. They provide the Project Manager with an opportunity to review the work
of the contractor. This provides for better quality control as mistakes can
be picked up early. This helps prevent expensive rework.
2. They provide the contractor with a payment point - the contractor knows
that if a certain amount of work is completed satisfactorily they will receive
all or part of the contract payment. This helps them plan their finances.

b. Performance Reviews

A review is a fancy way of saying - 'Have a look at what I have done and see if it
meets the requirements'.

This is normally done just before a milestone (as mentioned under 'milestones').

Q. What is used to conduct the review? OR What is the standard the work must
measure up to in order to be accepted?

A. The standards are normally documented in the contract. The more explicit they
are, the less likely there will be any disputes. Problems arise when the description
of the milestone and review are vague and the client's needs or tastes are evolving
as the project goes on. This can be frustrating for a contractor who is trying to
reach a milestone in order to get paid.

Example
Consider this short excerpt from a project WBS. It forms part of a contract to develop a
website:
2.4 Develop Page Look and Feel
2.5 Review Look and Feel
2.6 Look and Feel Signed Off (Milestone - payment of 25% of contract fee)
In this example, the Web Page Designer develops a concept and some templates for the
new website and reviews these with the client. If the client is happy with the work, the Web
Designer is paid 25% of the contract fee.

Review Objectives
You should regularly check to make sure you are meeting the project's requirements.

VERSION: 1.0, March 2018 | Week 7

© WELLS INTERNATIONAL COLLEGE 105
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 We suggest that you hold a regular project team meeting and, if appropriate, a regular
meeting with your client to review project progress against the contract, milestones and
stated objectives.
Remember, don't wait until the end of the project to check that you have done everything.

Project Management Tools

In the preceeding sections, we have introduced you to some commonly used project
management tools (such as budgets, work breakdown structure, gantt chart, critical path).
In a project environment, it is not only important to know how to use the tools, but how to
select the most appropriate tool for the task and for the environment you work in.
The selection and application of project management tools will depend on the
organisational culture you are working in. Some organisations are very small and have no
formal project management methodology. In this case, the tools selected will be very
simple and available to the organisation at little or no extra cost. Other organisations have
highly refined project management methodologies either because they have pursued this
area as an area of business excellence, or because they are required by another party to
have documented procedures for project management (eg. Contractors doing work for the
Government and the Military are required to have project management practices in place).
Of course there is a wide spectrum in between, as illustrated in the following diagram:

Diagram Source: [Link] accessed 21st May 2004.

If you wish to read more deeply on this topic of the implementation of project management
in organisations, you should research the PMMM (Project Management Maturity Model).
This 5 level model is based on SEI's Capability Maturity Model Integration.

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

106 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
Week 8

VERSION: 1.0, March 2018 |

© WELLS INTERNATIONAL COLLEGE 107
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 Perform quality assurance and quality control
Measuring throughout the Project
Planning for quality is an integral part of project planning. Quality is not something that is
inspected or tested at the end of a project. Quality should be a focus throughout all aspects
of the project. Once standards have been set, project activities need to be monitored,
measured and documented.

Triggers and schedules

The triggers to activate quality assurance tasks vary depending on the nature of the quality
attribute that you are assuring. Triggers for quality assurance tasks may be temporal - that
is, on a given day, at a given time, an activity takes place. Examples of temporal quality
assurance tasks include: weekly meetings, monthly reporting and scheduled testing.
Alternatively, quality assurance tasks may be triggered by the achievement of a
predetermined condition. Examples of predetermined conditions include: development of a
working prototype; completion of an integrated module and uploading of a module from
the development environment to the live environment. A third trigger can be unsatisfactory
results from tests or reviews; in this case the goal is to identify the cause of non-
conformance. Escalated quality assurance techniques can be used.

Project schedule
The project schedule should include tasks for quality assurance. Major checkpoints in the
project where key deliverables will be tested need to be clearly identified. Each process or
phase within the project must be structured to allow easy measurement of progress against
the specification.

Example Project schedule

A project plan has been developed for a theoretical project. The image below represents
the project schedule. The project was segmented into the four phases: Initialising, Planning,
Executing and Controlling.
 The Initialising phase involved a kick off meeting and development of a Project
Charter.
 The Planning phase involved developing project plans, but importantly the plans
were to be continuously reviewed and updated. This enabled the management of
project compression or expansion.
 The Executing phase involved analysis, design and implementation. The design
activity included scheduling for unit testing, system testing and user evaluation.
The number of tests was directly related to the duration of the design.
Implementation testing was to be a once-off activity, based on the approval of
the design.
 The Controlling phase included five status reports and the continuous updating of
performance reports. The project included a method for controlling changes.
Changes were to be completed before implementation.

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

108 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
The first Status Report indicated that the project was progressing better than planned. The
Charter had been prepared, the project plan had been completed in less time than
expected and data gathering had commenced. It appeared that the project was off to a
better than expected start - mainly due to the time saved in project planning.

The second Status Report indicated that while the gather data activity had commenced,
the activity appeared to be larger than initially expected. This meant that time saved in the
initial planning was consumed in analysis activities. In order to minimise lost time, some of
the design activities were initiated. It was reported that the project appeared to be on track
for completion by the expected date.

VERSION: 1.0, March 2018 | Week 8

© WELLS INTERNATIONAL COLLEGE 109
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 The third Status Report identified the extent of the gather data overrun. Requirements had
been approved and designing had commenced. The uncertainty in the gather data activity
prompted the project manager to develop the logical and physical designs at the same
time. It was expected that this method would speed the construction. Several unit tests had
been performed, with varying results. It was decided to increase the extent of testing to
ensure compliance with the requirements. While the project to date was running a little
behind it was still expected to finish on time.

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

110 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
The fourth Status Report clearly identified that the project schedule was blowing out.
The Logical Design activity was running behind schedule and the Physical Design activity
was estimated to extend past its allotted time. Project plans were adjusted and
management was advised of a new completion date.

The fifth Status Report indicated that the project was completed marginally after the
revised completion date.

Final report included a lessons learned segment.

The major lessons learned were:
 The initial planning was insufficient for the project and this led to overruns in
most activities. Recommendation: plan extensively for future projects.
 In this and other projects by this team, the gather data activity took longer than
expected. Recommendation: increase the expectation for data gathering by 50%.
 The logical design commenced before all the data had been gathered. In
addition, the physical design commenced shortly after the logical design began.
There were no issues associated with commencing high level design without all
the data. Indeed the commencement of the design prompted complete and
accurate data collection. Recommendation: Depending on the type of project,
analysis and design may be undertaken at the same time.
 Evaluation of scheduling trends enabled a reasonably accurate estimation of the
completion date. Recommendation: activity completion dates should be retained
for analysis and forecasting.

VERSION: 1.0, March 2018 | Week 8

© WELLS INTERNATIONAL COLLEGE 111
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 Product Performance
The product should be reviewed at regular intervals to check compliance against
specifications and standards. It is also important to review the processes that enable a
product to attain conformance to specifications.

Examples:

Test Report

Test Objective: Comments and layout of code

Code developers should provide comments within the code to enable other developers or staff
maintaining the code to understand the structure and purpose of the code.

Test methods

The code is scanned for human readability in the unit testing phase – a person other than the
developer scans the code.

Test results

Five pages of code were found to be without any comments at all

A further ten pages were found to have insignificant comments
Twelve pages were found to lack sufficient indentation to enable efficient human reading.

Implications

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

112 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
If pages are not commented there is a risk that the code will not be able to be maintained
appropriately in the future.

Recommendation

It is recommended that the pages identified are commented out by the code developer
It is recommended that each page of code is processed by an automated indentation or beautifying
tool.
HTML code beautifying tools can be found at: [Link]
Alternatively other tools can be purchased.

Action Plan

If non-conformance: The action plan documents the sequential process of implementing the
recommendation. Action plans may include the person responsible and the timeframe for
implementing the recommendation.
The tester may document the Action Plan. Alternatively and preferably the original developer
documents the Action Plan.

Causes and Compliance

On a regular basis the results of quality control activities and other relevant information
about the project and product should be analysed. This analysis will lead to the prompt
identification of general trends or issues and allow the early implementation of corrective
action.

Classifying defects
The IEEE Standard Glossary of Software Engineering Terminology provides a range of terms
to discuss defects, these include:
Error: "A difference…. between a computed result and the correct result".
Fault: "An incorrect step, process or data definition in a computer program".
Failure: "The [incorrect] result of a fault".
Mistake: "A human action that produces an incorrect result".
If an error or failure occurs, has it been caused by a fault or a mistake?
If it is a mistake, is it happening frequently and how can we minimise the occurrence of
mistakes?
If it is a failure, was it a fault that caused it and what needs to be rectified so that the failure
won't happen again?

VERSION: 1.0, March 2018 | Week 8

© WELLS INTERNATIONAL COLLEGE 113
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 Control Techniques
Quality control is the process that measures the quality of the project's deliverables.
Quality control occurs throughout the project, with a number of checkpoints defined where
progress and the quality of the current deliverables are reviewed in detail.

Examples of methods for quality control include:

 Review of deliverables through mechanisms such as self review, peer review and
structured walkthroughs
 Testing of deliverables to determine the level of compliance with user
requirements
 Assessing the satisfaction of stakeholders with the major deliverables of the
project
The major aspects of quality control are:
 Quality control is the responsibility of the entire project team
 Quality control should occur throughout the project, with an emphasis on major
project check-points
 If used, an independent quality assurance function will provide a second level of
quality control
 The outcome of the quality control activities must be a part of the project
reporting process
Source: Quality Management Guideline Office of information and communications
Technology NSW Government.

Maintaining a Quality Management System

You need to maintain records of quality to enable judgements about quality. You may
choose to use automated tools or manual tools to monitor quality outcomes. Where
possible use trusted automated tools.
MS Project is a good tool for scheduling activities. If you schedule your project in MS
Project, then you can enter in the actual durations for tasks and you will be able to identify
issues such as duration creep, overworked resources and slack time vs. the critical path.
View the following output from a well-maintained MS Project file and a poorly maintained
MS Project file.

Example

Well-maintained MS Project file Poorly maintained MS Project file

Duration Creep

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

114 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
Resource Allocation

Critical Path

VERSION: 1.0, March 2018 | Week 8

© WELLS INTERNATIONAL COLLEGE 115
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 The key here is that you must set up the system and maintain the system if you want to use
the outputs.

Capturing results
When you schedule Quality Assurance tasks, you should also establish the recording
mechanism. This can simply be a spreadsheet in which you can record results. Alternatively
you may establish a more formal test recording mechanism. The activities should be based
on your project schedule.

Example project schedule for testing

Example: Spreadsheet showing results of tests

Test
Clarification comments embedded in code:
name

Manually review code to check understanding and

Test
conformance:

Date 01/01 01/02 01/03 01/04 01/05 01/06

14 26 13 104 14 19
Result
failures failures failures failures failures failures

Action
14 fixed 23 fixed 10 fixed 80 fixed 32 fixed 12 fixed
taken

You may be required to provide a test results report to management.

Reporting to management
From time to time you will need to report to management, this may include a summary of
the Quality Assurance results. The project reports issued to management may include:

Status reports
Describes where the project stands at a specific point in time.

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

116 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
Progress reports
Describes what the project team has accomplished over a period of time.

Project forecasting

Predicts future project status based on past information and trends.

Summary
Quality management is a key component of a project and it is the responsibility of all
participants and stakeholders to support and promote the quality of the project and its
deliverables. Project Quality Management involves Quality Planning, Quality Control and
Quality Assurance.
Planning for quality involves: Selecting the Quality Assurance framework that will be
followed and communicating the quality mechanisms. Quality Control involves
implementing quality management tools and techniques. These include:
 Cost/benefit analysis
 Benchmarking
 Flow-charting
 Design of experiments
 Quality audits
 Inspection
 Control charts
 Pareto diagrams
 Statistical sampling
 Trend analysis
When classifying non-conformance and defects it is important to identify if it has been
caused by a fault, or a mistake and if the defect is an error or a failure. It is also important
to identify if the defect is an isolated case, or part of a pattern that will result in the
problem recurring.
Corrective action should be considered. This may include: Reworking of a deliverable;
Changing of methods or standards; Refinement of the project structure; or Changing the
project plan and/or the Quality Assurance framework.

VERSION: 1.0, March 2018 | Week 8

© WELLS INTERNATIONAL COLLEGE 117
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 Week 9

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

118 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
Project closure
All good things must come to an end. Projects are designed to end at some point as that is
the nature of project work. To gain maximum benefit from a project, the project should go
through a formal close down. You should have planned for closure during the Planning
Phase of your project.
Project closure is the fourth major phase of a project’s lifecycle. It is during this phase that
the project is reviewed and any lessons learned from it are used to improve future projects.
Project closure is often the most neglected stage of project management. Once the
implementation phase has been successfully completed there is usually a period of relief
followed by a desire to move on to more productive fields such as new and challenging
future projects. Responsibility for wrapping up all the loose ends may be passed to a junior
project manager or the project may just fade away for lack of resources or interest.
Important lessons may not be learned, genuine evaluation on the success or failure of the
project may not be gained and the organisation may blunder into the future none the wiser
from the experience.
In some cases, closure may be because the project failed. If so, there may be little
enthusiasm for rubbing salt in the wound by going over past mistakes. However, some of
the best lessons for future improvements can be gained by evaluating failed projects.

⇒ Remember – that it is normal for complex projects to be only partially successful.

Nobody gets excited about project closure. That isn’t to say that nobody wants to complete
their projects, or that people don’t want to judge how successful projects have been. It’s
just that the associated routine (or process) and paperwork never seem as important as the
myriad of other things that a project manager and his/her team must do as a project, or a
stage of one, is being closed. The work has been done, the customer has what he or she
wants, and everybody’s mind is moving on to the next project or challenge.
Project managers, project sponsors, and project team members alike will readily
acknowledge the importance of project closeout management. The logic is unquestionable.

 If adequate product records are not kept, whole-life costs of the product are likely
to increase.
 If there is no deep and thorough understanding of where reality has diverged
from plans, there is little hope of making better plans next time.
 If time is not taken to reflect on the lessons of the past, the likelihood is that
similar mistakes will be made in the future.
 If project relationships are not brought to a satisfactory closure, unresolved issues
and resentments may smoulder beneath the surface, ready at any time to erupt
with unpleasant consequences.

Closeout management activities

The final phase of the project provides the opportunity to capture and transfer project
knowledge for use in future projects. Once the project has been completed provision
should be made to archive the files and enter the project information into the appropriate
database. Closing involves formalising the acceptance of results and ending the project.

VERSION: 1.0, March 2018 | Week 9

© WELLS INTERNATIONAL COLLEGE 119
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 Finish the Work
As the project nears completion, there is a natural tendency for members of the team to do
sufficient work to meet time and overall quality standards, while leaving a number of small
elements of the work outstanding. There may also be issues that have emerged at various
times during the life of the project and have yet to be resolved.
To ensure that the work is actually finished, create a checklist of the outstanding tasks and
issues and use it as a control mechanism.

Handover the product

No matter what type of project has been undertaken, there will be some sort of “handover”
required. Remember: the end-users won’t share the same insights and knowledge about
the product as the project team who created it. Implementing the Handover Plan includes:
 Transfer of responsibility over to the operational managers and staff:
 Transfer of physical deliverables
 Training of users
 Sharing of technical designs and important design concepts
 Provision of drawings and specifications, etc.

Gain Acceptance for the Product

Projects need a clear cut-off to signal the end of handover and the transfer of full
operational responsibility from the project team to the client/customer. Gaining
acceptance is not as simple or straightforward as it might appear for the following reasons:
 Client may lack confidence in his or her ability to manage the product or service
effectively without ongoing support
 Client may doubt his or her ability to deliver the benefits from the product or
service on which the business case was built, and there will no longer be anyone
else with whom to share the blame.
 Client maybe receiving adverse comments from end users who were never
convinced of the merits of the project in the first place.
 Client may have come to realize in the course of the project that what they really
want isn’t the product or service that the project has delivered, and as long as no
acceptance has been signed, it might be possible to improve the match.

Project completion report

The Project Completion Report is normally distributed to all stakeholders as a means of

encapsulating everything that occurred during the project and describing anything that
could have been done better. The following details should be included:

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

120 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
Summary or Overview
 Brief background to the project
 Summary of the project’s performance and its outcomes

Performance against Scope, Objective, Schedule, Budget and Quality

A thorough review of the project to compare what the project set out to achieve and what
it actually achieved:

 Changes to the Project objective

 The project selection methods
 Achievements and failures of the project
 Schedule comparisons against the plan
 The extent that risk affected the project
 Magnitude and impact of changes
 Accuracy of forecasts and estimates
 Timeliness and appropriateness of the corrective action taken
 Lessons learned
 Recommendations for future projects

Project Management Aspects

A review of the project management approach adopted throughout the project:

 The appropriateness of the methodology in managing changing expectations

 The inclusion of relevant stakeholders in decision making
 The lessons learned
 The suitability and flexibility of the documentation used
 Stakeholder ‘buy-in’ to the methodology.

Recommended Improvements
 Outline how you will apply the lessons learned to future projects

SWOT analysis
A SWOT analysis helps to answer key questions and create a better organisational strategy
by answering the following types of question:
 Does the organisation have the internal strengths on which to build an attractive
strategy?
 Which weaknesses does strategy need to correct?
 Do the organisation's weaknesses disqualify it from pursuing certain
opportunities?

VERSION: 1.0, March 2018 | Week 9

© WELLS INTERNATIONAL COLLEGE 121
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
  Which opportunities does the organisation have resources to pursue with a
chance of success?
 What threats should the organisation worry most about?

The internal environment

(What is happening within the organisation and what are the effects?)
Through an analysis of the internal environment an organisation can determine what it can
do, or the actions that it can undertake based on the resources, core competencies and
capabilities available.

Resources
Resources are inputs from the organisations production process. Examples of resources
include:
 Capital equipment
 Skills of individual employees
 Patents
 Finances
 Talented managers.
Generally an organisation has both tangible and intangible resources.
Tangible resources are assets that can be seen and quantified, including assets like
production equipment, manufacturing plants and formal reporting structures.
Intangible resources include assets that are rooted deeply in the history of the organisation
and that have accumulated over time, including knowledge, trust between managers and
employees, ideas, the capacity for innovation, managerial capabilities and reputation.
Intangible resources are difficult for competitors to understand and copy.

Capabilities
Capabilities are the knowledge and skills of employees. This is seen as one of the most
relevant sources of competitive advantage for any organisation. They must find ways to
share this knowledge and skills with the rest of the organisation. Only when a capability is
valuable, rare, costly to imitate and unable to be substituted, is it a core competency and a
source of competitive advantage.

Core Competencies
An effective internal environment analysis includes identifying both what are and what are
not the organisations core competencies. Core competencies refer to activities of the
organisation which create unique value. These activities are not necessarily ones on which
the organisation spends the most time, but those that have the potential to create
sustained competitive advantage.

Competitive advantage
Competitive advantage is the ability of the organisation to outperform its competitors in
key performance areas. Competitive advantages may arise through the external
environment, for example, changes in customer demand, fluctuations in prices and the

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

122 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
impact of advances in technology. Competitive advantages may also arise as a result of
internal activities, for example, restructuring of the organisation.

Analysis of the Internal Environment helps to understand the Strengths and Weaknesses
that face the organisation.
The following table lists some of the questions to ask to determine the Strengths and
Weaknesses of the organisation.

Example
Strengths Weaknesses

What are our advantages? What could be improved?

What do we do well? What is done badly?

What are our major strengths and how can What are our main weaknesses and how can
we utilise them in the future? we overcome them?

What must we do to strengthen our IT How should we address weaknesses in IT

function, including our people and technology resources and capability?
infrastructure?

A distinctive competence? No clear strategic direction?

Adequate financial resources? A deteriorating competitive position?

Good contacts/relations with clients? Low profitability because...?

Good competitive skills? Lack of managerial depth and talent?

Special expertise? Proven management? Missing any key skills or competencies?

An acknowledged market leader? Poor track record in implementing strategy?

Well-conceived functional area strategies? Plagued with internal operating problems?

Innovative programs/services? Vulnerable to competitive pressures?

Good overall reputation? What should be avoided?

Access to economies of scale? Weak market image?

Insulated from competitive pressures? Competitive disadvantages?

Cost advantages? Below-average marketing skills?

Competitive advantages? Unable to finance changes in strategy?

VERSION: 1.0, March 2018 | Week 9

© WELLS INTERNATIONAL COLLEGE 123
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 The External Environment
(How do external factors like customers / competitors affect the organisation?)
An understanding of the external environment helps organisations to understand their
current situation and predict future trends.

Industry Environment
An industry is a group of companies producing products that are close substitutes.

Example
The Web Design Industry is made up of individual web design and development companies,
including ISPs.
The industry environment has a more direct effect on strategic competitiveness.

Competitor Environment
Competitor analysis enables an organisation to focus on each rival company and gather
information about them.
When doing competitor analysis, companies seek to understand:
 What drives the competitor, as shown by future objectives
 What the competitor is doing and can do, as shown by its current strategy
 What the competitor believes about itself and the industry
 What the competitors capabilities are

Analysis of the External Environment helps to understand the Opportunities and Threats
that face the organisation.
The following table lists some of the questions to ask to determine the Opportunities and
Threats of the organisation.

Example

Opportunities Threats

What are our major opportunities and how can What major threats do we face and what can
we take full advantage of them? we do about them?

What IT plans do we have to support business What can we do to deal with potential threats
opportunities? to IT success?

What are the interesting trends? What obstacles do we face?

Changes in technology and markets? What is our competition doing?

Expand service line to meet broader range of Are the required specifications for our job,
client needs? products or services changing?

Are there changes in social patterns, population Is changing technology threatening our
profiles, lifestyle changes? position?

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

124 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
Will local events provide opportunities? Do we have bad debt or cash-flow problems?

Serve additional customer groups? Likely entry of new competitors?

Enter new markets or segments? Slow market growth?

Changes in government policy? Adverse government policies?

Diversify into related services? Growing competitive pressures?

Complacency among rival organisation s? Vulnerability to recession and business cycle?

Fast market growth? Growing bargaining power of clients?

Weak competitors? Changing client needs and tastes?

Lack of dominant competitor? Adverse demographic changes?

The outcome of the SWOT analysis is a series of lists, one each for strengths, weaknesses,
opportunities and threats.

VERSION: 1.0, March 2018 | Week 9

© WELLS INTERNATIONAL COLLEGE 125
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 Project evaluation and follow-up activities
A project that seems successful from the point of view of one set of stakeholders might
appear to have failed when seen from another viewpoint. A project completed on time and
within budget might look splendid at the time of project closeout, but a year later, with the
benefit of hindsight, it might appear to have been a big mistake. Different groups of
stakeholders need to:
 Agree at the BEGINNING, precisely what will constitute “project success”
 Review the project at the end to see what degree of success was actually
achieved
 The review is carried out in two phases:
o Post-Project Review (lessons-learned)
o Post-implementation (business benefits)

Analyse Project Outcomes

When we have completed the project, we need to ask hard questions like:
 What was I trying to accomplish?
 Did I accomplish it?
 Can I prove that I accomplished it?
Let's examine each of these questions in turn:

What was I trying to accomplish?

 You should have a clear statement of the scope of the project
 You should have a list of functional requirements (these form the acceptance
criteria)
 You should also have a list of standards that your project should conform to (they
will be found in the business requirements and technical specifications which
were developed in the initial phases of the project), for example:
o The website must meet all of the customer's requirements (yes, this is a
standard!)
o The website should conform to all relevant accessibility standards

Did I accomplish it? Can I prove it?

 During the project and at its completion, you should check that you are following
all of the project standards - ie. That you are building the RIGHT PRODUCT in the
right way.
 The best way to do this is to regularly review (or audit) your achievements
against the standards and scope/objectives of your project.
 This is called 'programmed review' and, as mentioned earlier, is a quality
assurance activity.
 Regular reviews should be built into your project schedule.
 DON'T WAIT UNTIL THE FINISHED PRODUCT IS READY TO START REVIEWING AND
TESTING - TEST EARLY AND OFTEN.
 This can pick up errors and departures from scope and standards which could be
embarrasing and costly if they are left in until the end.
 The results of these reviews should be communicated to the relevant
stakeholders.

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

126 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
Example
You are developing a website for a furniture shop. You get to the stage where all of the
major functions are finished and there are some products in the site's database. You make
an appointment with your client and review the site together, noting the client's concerns.
You use a checklist which lists all of the functional requirements. As you and your client
review each function, you both sign it off on the checklist. This helps you not only conduct
the review, but prove that you conducted it.
Support Arrangements
Sometimes your client will require or request support for the project you are developing. If
your product is a website, you will probably offer to support the website with things like
help desk, programming, content writing and updating, link checking and such things.
This will involve setting up an agreement between you and your client.

Post Project Review (lessons-learned)

 Undertaken while members of the project team have the actual events of the
project still fresh in their minds
 Purpose is to reflect on the events that took place in the course of the project and
consider what might have been done differently to improve the results obtained
 Led by the Project Manager or Project Sponsor
 Attended by representatives from all significant partied that contributed to the
project
 Likely to be based on a comparison between the actual results and the conduct of
the project, project proposal and project plan
 The results should then be communicated to everyone who needs to know what
happened

Business Benefits or Post-Implementation Review

 Held some months after the product or service has been in operation, when the
benefits can be more accurately assessed
 Purpose is to establish the extend to which the product of the project is delivering
the anticipated benefits
 Based on a comparison between actual operating benefits being harvested and
those predicted in the project proposal or business case
 Focus is on the operation and the impact on benefits of decisions made during the
establishment and execution of the project
 The results should be communicated widely to the appropriate audience

Continuous Evaluation & Improvement (Status) Review

As well as conducting a post-project review, it is important to continuously evaluate and

review the project. At the end of each phase a number of actions should occur:

VERSION: 1.0, March 2018 | Week 9

© WELLS INTERNATIONAL COLLEGE 127
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
  A check is carried out to confirm that all work is completed and that the phase
has achieved its objectivise
 The project plan is checked to ensure that all of the activities within it are either
carried out or there has been good reason not to
 All documentation is finalised
 The phase is “signed off”
 The phase is reviewed, issues for further action are noted, lessons learned are
captures and recommendations are put forward to the appropriate authority for
inclusion in future phases

Implement project quality improvements

The age-old saying "If it isn't broke - don't fix it" has been upgraded and improved for the
new age. The attitude of successful people is now "If it's not perfect - improve it".

Continuous Improvement
Continuous improvement is a term used to describe the incremental improvements that
take place over time as the results of corrective actions are fed back into the Quality
System. Continuous improvement strives to reduce the recurrence of repetitive quality
problems.

Quality improvement standards

ISO 9004-4 explains how to develop and implement a quality improvement program. ISO
9004-4 suggests that quality improvement refers to a set of activities whose purpose is to
enhance efficiency and effectiveness for the benefit of the organisation and its customers.
Improvements can be achieved by looking for ways to improve process efficiency and
effectiveness. The elements associated with ISO 9004 include:
 Develop a quality improvement program
 Create a socio-cultural environment that supports quality improvement
 Reduce or avoid quality losses
 Create a structure that supports quality improvement
 Define quality improvement responsibilities
 Develop a quality improvement planning process
 Develop a quality improvement measurement system
 Develop a quality improvement review procedure
 Carry out quality improvement projects
 Analyse the facts before you decide to make quality improvements

Determine the quality effectiveness

At the end of the project, the product that you build is ultimately accepted or rejected by
the client/customer based on the attainment of the functional requirements, non-
functional requirements, system specifications and the adherence to agreed standards.

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

128 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
Acceptance by the client/customer will determine the effectiveness of the product, but it
does not necessarily determine the effectiveness of the quality management system.
The effectiveness of the quality management system is determined by reviewing the results
of quality records.
 If there have been improvements in quality results over the duration of the
project, the quality management system has been effective.
 If there are improvements in quality results from one project to another project,
the quality management system has been effective.
 If you have recorded lessons learned and the learning is implemented in another
project, the quality management system has been effective.
 If you don't have any quality records the quality management system doesn't
exist.

Lessons Learned
Lessons learned should be captured and communicated. Lessons learned are the good and
bad things that you managed over the project.
Many organisations enable searching on lessons learned, this forms a valuable resource for
organisations. Lessons learned can also be a source of competitive advantage; therefore
most organisations will not enable public access to their databases.

VERSION: 1.0, March 2018 | Week 9

© WELLS INTERNATIONAL COLLEGE 129
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 Research and resources
References
Learning activities mostly extracted from the following books:
 Absolute Beginner's Guide to Project Management (2nd Edition) Greg Horine
 Information Technology Project Management (Revised 6th ed.) Kathy Schwalbe,
 The project management: best practices for IT professional, by Richard Murch,
 A Guide to the Project Management Body of Knowledge: (PMBOK(r) Guide, 4e
 Managing for Quality and Performance Excellence (8th edition), by James R.
Evans, William M. Lindsay

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

130 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
Books:
There are many appropriate related books in the market, and you may select from the books list
above whatever suits you and the situation or advised by your trainer. It is handy to do a search on
different local bookshop websites, and use keywords. A useful bookshop website is:
[Link]

Websites:
 Search engines:
[Link]
[Link]
[Link]
[Link]
[Link]
 Answers:
[Link]
 Tech Republic:
[Link]
 Project scope:
[Link]
 Critical path:
[Link]
Provides a detailed discussion of critical path
 Estimating methods:
[Link]
Provides a short, concise summary of estimating methods
[Link]
[Link]
4&Origin=CH010427261033
Try these links for using different methods to estimate cost
[Link]
This deals mainly with parametric estimating based on the size of software projects.
However, it contains a lot of other information on estimating which is handy to keep in
mind.
 Financial baselines:
[Link]
3&Origin=HP452950251033
Provides an excellent summary of baselines
 Gantt charts:
[Link]
Contains a lot of helpful information

VERSION: 1.0, March 2018 | Research and resources

© WELLS INTERNATIONAL COLLEGE 131
CRICOS PROVIDER CODE: 01856K RTO NO. 90501
 [Link]
Another good link for introductory material
 Project Implementation:
[Link]
 Dispute resolution:
[Link]
[Link]

Intractable Conflict: this is an entire course on diplomacy and dispute resolution - FREE!
[Link]
Excellent and practical hints on how to AVOID disputes
 Training - Project 2007 - Microsoft Office
[Link]
PMP Exams Preparation (PMBOK Guide 4th Edition) Download 4th edition free

Additional Lecture Notes

Any additional aid (lecture notes/books) required could also be uploaded on the
student/share drive during the training.

ICT PROJECT MANAGEMENT LEARNERS' GUIDE | VERSION: 1.0, March 2018

132 © WELLS INTERNATIONAL COLLEGE
CRICOS PROVIDER CODE: 01856K RTO NO. 90501