CSIT 310 Design Project

CSIT 310
Design Project
Session 0 – Introduction to Design Project
Lecturer: Dr. Ferdinand Katsriku, CSD

Contact Information: fkatsriku@ug.edu.gh
College of Education
School of Continuing and Distance Education
2016/2017 – 2017/2018
Introduction
• Why is Software Project Management Important?
• • Money
• – 2002-2003 UK government spent more on contracts for ICT
projects than on contracts related to infrastructure
• • Projects are not successful
• – Standish group report:
• In 2003 only 1/3 of projects were successful • 82% were late
• 43% exceed their budget
All material presented in this course is based on the

book by D. Dalcher and L. Brodie Successful IT
Why do software projects fail?
• People begin programming before they understand
the problem
– Everyone likes to feel that they’re making progress
– When the team starts to code as soon as the project
begins, they see immediate gains
– When problems become more complex (as they always
do!), the work gets bogged down
– In the best case, a team that begins programming too soon
will end up writing good software that solves the wrong
problem
All material presented in this course is based on the book by

• The team has an unrealistic idea about how much
work is involved.
– From far away, most complex problems seem simple to
solve
– Teams can commit to impossible deadlines by being overly
optimistic and not thinking through the work
– Few people realize the deadline is optimistic until it’s
blown

• Defects are injected early but discovered late.
– Projects can address the wrong needs
– Requirements can specify incorrect behavior
– Design, architecture and code can be technically flawed
– Test plans can miss functionality
– The later these problems are found, the more likely they
are to cause the project to fail

• Programmers have poor habits – and they don’t feel
accountable for their work.
– Programmers don’t have good control of their source code
– Code written by one person is often difficult for another
person to understand
– Programmers don’t test their code, which makes
diagnosing and fixing bugs more expensive
– The team does not have a good sense of the overall health
of the project.

• Managers try to test quality into the software.
– Everyone assumes that the testers will catch all of the
defects that were injected throughout the project.
– When testers look for defects, managers tell them they are
wasting time.
– When testers find defects, programmers are antagonized
because they feel that they are being personally criticized.
– When testers miss defects, everyone blames them for not
being perfect.

How can we make sure that our projects
succeed?
• Make sure all decisions are based on openly shared
information
– It’s important to create a culture of transparency, where
everyone who needs information knows where to find it
and is comfortable looking at it.
– All project documents, schedules, estimates, plans and
other work products should be shared with the entire
team, managers, stakeholders, users and anyone else in
the organization who wants them.
– Major decisions that are made about the project should be
well-supported and explained.

succeed?
• Don’t second-guess your team members’ expertise
– Managers need to trust team members.
– Just because a manager has responsibility for a project’s
success, it doesn’t mean that he’s more qualified to make
decisions than the team members.
– If you don’t have a good reason to veto an idea, don’t.

succeed?
• Introduce software quality from the very beginning
of the project
– Review everything, test everything.
– Use reviews to find defects – but don’t expect the review
to be perfect.
– Use reviews to gain a real commitment from the team.
– It’s always faster in the long run to hold a review than it is
to skip it.

succeed?
• Don’t impose an artificial hierarchy on the project
team
– All software engineers were created equal.
– A manager should not assume that programming is more
difficult or technical than design, testing or requirements
engineering.
– Managers should definitely not assume that the
programmer is always right, or the tester is always raising
false alarms.

succeed?
• Remember that the fastest way through the project
is to use good engineering practices
– Managers and teams often want to cut important tasks –
especially estimation, reviews, requirements gathering and
testing.
– If it were faster to build the software without these
practices, we would never use them.
– Every one of these practices is about saving time and
increasing quality by planning well and finding defects
early. Cutting them out will cost time and reduce quality.

Session Overview
At the end of this session, students should be able to
• Understand the subject matter of this course – Introduction to
Design Project
• Become familiar with the tools in the Sakai LMS to be used in
the course.
• Do self-introductions and discuss the expectations for the
course in the Chat Room

Session Outline
The key topics to be covered in the session are as follows:
• Aims and Objectives
• Learning Outcomes
• Course Organization
• Session Overview

Reading List
• Darren Dalcher & Lindsey Brodie Successful IT Projects
• Hughes, B and Cotterell, M (2009) Software Project Management (5e)
MGraw-Hill Higher Education  
• Schwalbe, K (2013) An introduction to project management. (4e) Schwalbe
Publishing  
• Lock, D (2014) Essentials of Project Management. Gower

Topic One
AIMS AND OBJECTIVES

Aims and Objectives
• The general aims of the course are
• To allow prepare you to undertake a significant piece of
individual work.  
• To develop an awareness of the need for project
planning and management.  
• To foster a professional attitude and the use of
appropriate techniques and tools in the
 management of IT projects  

Aims and Objectives
• Objectives
•  Upon successful completion of this course, you will be able to demonstrate
competence in, and ability to:  
• Identify and investigate a topic which has a computer-based solution.
 
• Research the literature, evaluate possible solutions, and select the most
appropriate  solution.  
• Explain the stages in the system development lifecycle and the activities
that are carried out to implement an IT application;  
•

Aims and Objectives
• Objectives
•   Apply basic project planning techniques  
• Demonstrate an understanding of steps needed to build and maintain effective
development  teams;  
• Explain the procedures needed to monitor, control and report upon an IT
development  project;  
• Discuss and where appropriate apply the principles of project risk management.
 
• Explain the ways in which appropriate quality attributes of the products of an IT
development  project can be assessed and assured.

Topic Two
LEARNING OUTCOMES

Knowledge
• Identify and investigate a topic which has a computer-based
solution.  
• Research the literature, evaluate possible solutions, and select
the most appropriate  solution.  
• Explain the stages in the system development lifecycle and
the activities that are carried out to implement an IT
application;  
• Demonstrate an understanding of steps needed to build and
maintain effective development  teams;

Skills
• Apply basic project planning techniques  
• Investigate a problem and identify the needs of users
of the computer-based solution.
• Produce a specification of the requirements.  
• Identify milestones to provide project management.
 
•  

Competencies
• Explain the procedures needed to monitor, control
and report upon an IT development project;  
• Discuss and where appropriate apply the principles
of project risk management.  
• Explain the ways in which appropriate quality
attributes of the products of an IT development
 project can be assessed and assured.  

Competencies
• Produce a formal proposal to a professional standard
for an individual project.
• Produce a detailed and coherent project report to a
professional level of presentation.
• Produce an in-depth critical appraisal of both the
product and the process of the project, including
personal reflection.
• Evaluate how the solution and process might be
improved in future.

Topic Three
COURSE ORGANIZATION

Course Organization
• Assessment
• Individual Assignments
• Submission and deadlines

Assessment

Individual Assignments
• Individual assignments will be provided at end of
sessions. These assignments may be in the form of
Multiple Choice Questions (MCQs), project work
and/or presentation. Deadlines will be provided for
each assignment with respect to scheduling of the
sessions.

Submission and deadlines
• Penalty for late submission of work:
• 1 day late 5% of marks lost
• Up to one week 10% of marks lost
• 1 week<late<=2 weeks 20% of marks lost
• More than 2 weeks 25% of marks lost

Topic Four
SESSION OVERVIEW

Session 0
• INTRODUCTION TO CSIT 310
– Overview
• Introductions and orientation to the use of the Sakai
Learning Management System (LMS) and the available
tools for the course.
– Goals and Objectives
• At the end of the session, the student should be able to:
• Understand the subject matter of this course –
Introduction to Design Project

Session 1
• PROJECT AND PROJECT MANAGEMENT
• Goals and Objectives
• Describe the characteristics of projects
• Outline project management activities
• Understand the criteria for successful projects
• Describe in overview the project lifecycles
• Explain the different systems development lifecycle
approaches and models

Session 2
PROJECT SELECTION
Goals and Objectives

At the end of the session, the student should be able to:
Understand how a project must fit (align) with organizational objectives
Describe the concepts of programme management and portfolio management
Explain the project management perspective on objectives, scope, stakeholders and
stakeholder value
State the main contents of a feasibility study

Session 3
• RESEARCH METHODS
•
• Outline the different research philosophies (postpositivism,
constructivism, advocacy and pragmatism)
• Understand the different research approaches (quantitative,
qualitative and mixed methods)
• Describe the different research methods including experiment,
survey, case study, action research narrative, grounded theory and
ethnography
• Understand the different data collection methods including
sampling, secondary data (documentation, survey and multiple
sources), observation, questionnaire and interview

Session 4
• MANAGING PROCESS AND CHANGE
• At the end of the session, the student will be able to
• List the main project deliverables
• Outline the different types of testing
• Explain some of the issues associated with managing
change
• Discuss configuration management
• Describe two types of project management review
Session 5
• PROJECT PLANNING
•
• Produce a work breakdown structure (wbs)
• Construct a project activity network diagram
• Analyse a project’s critical path
• Discuss the use of project management applications 

Session 6
• COST MANAGEMENT
• Understand the place of cost management within
project management
• Outline a process for cost estimation
• Describe COCOMO II and other methods used for cost
estimation
• Explain the use of earned value management (EVM) for
cost control

Session 7
• LEADERSHIP AND TEAMWORKING
• Discuss the importance of people factors in projects
• Explain the role of an effective project leader in an IT
project
• Identify and explain the key factors in creating positive
teamwork
• Discuss some ethical and cultural issues relevant to
projects

Session 8
• PROJECT QUALITY MANAGEMENT
• Understand the importance of quality management
• Describe the main processes of project quality
management and understand how they relate to
projects
• Describe several quality control techniques
• Understand the contribution of the major quality
experts to quality management
• Discuss quality standards and models

Session 9
• PROJECT RISK MANAGEMENT
•
• Define risk
• Define risk management
• Identify and evaluate risks
• Utilise checklists and other generic lists to determine
project risks
• Categorise and prioritise action lists for risks
• Discuss strategies for dealing with project risks

Session 10
• PROJECT REVIEW AND REFLECTION
• Goals and Objectives
• At the end of the session, the student should be able
to
• Understand how to carry out an end-of-project
evaluation
• Reflect on project events, problems and deliverables
• Adopt a professional attitude to continuous
improvement and personal development in project
work

END
• Thank you

CSIT 310
Design Project
Session 1 – PROJECT AND PROJECT MANAGEMENT

2016/2017 – 2017/2018
Session 1:
Introduction to projects and

project management
2016/2017 – 2017/2018
Session Overview
– Overview
• This course introduces you to the basics of project
management. It will provide a rich experience of what
you will meet in industry as well as a sound
foundation for your final year project. We will work
through the phases of a technical project. In this first
session, we will talk about the characteristics of a
project, the main project management activities we
need to be aware of, those criteria that define a
successful project and we will also take a look at
project life cycles.
Learning outcomes
• Describe the characteristics of projects
• Outline project management activities
• Understand the criteria for successful projects
• Describe in overview the project lifecycles
• Explain the different systems development
lifecycle approaches and models

What is a project?
• Dictionary:
• – A specific plan or design; a planned undertaking; a
large undertaking, e.g., a public works schema
“A temporary endeavor undertaken to create a unique

product, service or result.”
(PMBOK 2004)
• A definable purpose
• A unique undertaking
• A temporary activity

What is a project?
• Characteristics that distinguish projects
• – Non-routine tasks are involved
• – Planning is required
• – Specific objectives are to be met or a specified product is to be created
• – A predetermined time span
• – Work is carried out for someone other than yourself
• – Work involves several specialists
• – Formed temporary work groups to carry out the task
• – Work is carried out in several phrases
• – Available resources are constrained
• – Project is large and complex

Why undertake a Project
• Stakeholder value
• Innovation
• Organisational change
• Resource utilisation
• Timescales
• Financial cost
• Resource availability
• Organisational scope

Discussion
• Producing edition of a newspaper
• Putting a robot vehicle on Mars to search for signs of life
• Getting married
• Building the channel Tunnel
• Research what makes a good human-computer interface
• Writing an operating system for a new computer
• Installing a new version of a wordprocessing package in an
organization
• A second-year programming assignment for a computing
students
• An investigation into why a user has a problem with a
computer

What distinguishes Software from
other Projects
• Invisibility
– Bridge versus Software – Progress is not visible
• Complexity
• – Software projects are more complex than other engineered
artefacts –proved in numerous cases
• Conformity
• – Governed by physical laws –
• cement and steel
• – Requirements to human clients
• Flexibility
• – Software is easier to change
• – Software will change to accommodate the environment rather
than vice versa

What is project management?
“The application of knowledge, skills, tools, and
techniques to project activities to meet the
project requirements.” (PMBOK 2004)
“Project management is the process by which

projects are defined,planned, monitored,
controlled and delivered such that the agreed
benefits are realised.” (APM BoK 2006)

Project Management
• The project manager plans and guides the software
project
– The project manager is responsible for identifying the
users and stakeholders and determining their needs
– The project manager coordinates the team, ensuring that
each task has an appropriate software engineer assigned
and that each engineer has sufficient knowledge to
perform it
– To do this well, the project manager must be familiar with
every aspect of software engineering

Project management
process groups
• Initiating processes
• Planning processes
• Executing processes
• Monitoring and controlling processes
• Closing processes
(PMBOK 2004)

Project management
knowledge areas
• Integration management
• Scope management
• Time management
• Cost management
• Quality management
• Human resources management
• Communications management
• Risk management
• Procurement management (PMBOK 2004)

Success criteria for projects
A project should be completed:
– Within time
– Within budget
– At the desired performance levels
– With acceptable quality
– Offering at least the minimum agreed functionality
– Utilising the assigned resources effectively and
efficiently
– Accepted by the client
– Used by the intended users
– Delivering the promised benefits

Factors influencing project failure (Yardley 2002)
Technical Failure Human Failure Process Failure

Lure of the leading edge Lack of executive support Absence of any project
management methodology
Poor technical design Lack of leadership Absence of any systems
development methodology
Technical solution to a non-technical Uncommitted project team Absence of any benefits
problem management methodology
Dependence on software packages to Dysfunctional project team Failure to identify and mitigate
satisfy requirements project risks
Lack of tools throughout development Failure to manage third parties Failure to manage
lifecycle requirements
Technology-led development Lack of a project ‘champion’ Lengthy project timescales
Lack of project ownership Insufficient testing
Stakeholder conflict ‘Big-bang’ approach to
computerization
Resistance to change
Hostile organizational culture
Inexperienced project managers
Lack of business justification
Unclear or ambiguous business
priorities
Project lifecycles
Project management lifecycle Manage the

project
Systems development lifecycle Modify the

system
System Lifecycle
Project Start Project End

Project management lifecycle
• Concept
• Definition
• Implementation
• Handover and closeout
(APM BoK 2006)

Systems development lifecycle
approaches
• Sequential
• Incremental
• Prototyping
• Evolutionary

Systems development lifecycle models
• Waterfall model
• Incremental phased delivery
• Evolutionary delivery (Evo)
• Spiral model
• DSDM (Dynamic Systems Development Model)
• RUP (Rational Unified Process)
• XP (Extreme Programming)

The Waterfall Model
System
Requirements
Software Winston Royce 1970

Requirements
Analysis
Program
Design
Coding
Testing

Incremental Delivery
Waterfall Models
Increment 1
Increment 2
Increment 3
Increment 4
Increment 5
Phase 1 Phase 2 Phase 3 Phase 4 Phase 5

Delivery to Delivery to Delivery to Delivery to Delivery to
Customer Customer Customer Customer Customer
of Increment
All material presented in this course is based1on the
of Increment 2 of Increment 3 of Increment 4 of Increment 5
Crashed Increments
Increment 1
Increment 2
Increment 3
Increment 4
Increment 5
Delivery to customer
on completion of each increment

Evo Result Cycle
Feedback ‘Go’
Strategic
Management
Cycle ‘The Head’
Development
Tom Gilb Cycle Backroom
‘The Body’
Evo was developed Production
from 1976 onwards
Cycle Backroom
Delivery
Cycle Frontroom
Spiral Model
Barry Boehm 1988

Identify and
Determine Risk Analysis resolve risk
objectives
Risk Analysis
Risk Analysis
Risk Analysis
Operational
Review Prototype 1 Prototype 2 Prototype 3 Prototype
Requirements plan
Requirements
Design
Requirements Detailed
Development plan validation Design
Code
Design verification
Integration and test plan
and validation
Test
Plan next phase Service Develop and

book by D. Dalcher and L. Brodie Successful IT verify
DSDM Overview
DSDM Consortium Feasibility

About 1994
Business Study
Implement
Agree schedule Review

business Implementation Train users
Create Functional Identify
functional model functional
prototype User approval and
prototype iteration user guidelines
Review prototype
Identify design prototypes
Agree Design and Review

schedule build iteration design
book by D. Dalcher and L. Brodie Successful IT prototypes
Rational Unified Process (RUP)
Rumbaugh et al 1999
Inception Elaboration Construction Transition

Plan-Do-Study-Act Plan-Do-Study-Act Plan-Do-Study-Act Plan-Do-Study-Act
Cycles Cycles Cycles Cycles

Summary
• What is a project?
• Project characteristics
• What is project management?
• Project management process groups and knowledge
areas
• Project success and failure criteria
• Project management lifecycle
• Systems development lifecycle approaches
• Systems development lifecycle models

Reading List
• Darren Dalcher & Lindsey Brodie Successful IT Projects
• Hughes, B and Cotterell, M (2009) Software Project Management (5e)
MGraw-Hill Higher Education  
• Schwalbe, K (2013) An introduction to project management. (4e) Schwalbe
Publishing  
• Lock, D (2014) Essentials of Project Management. Gower

Exercises
• List the problems you experienced when you carried out a
recent IT assignment. Rank this problems in order of
magnitude and consider whether some of the problems could
have been reduced through better organization or planning by
yourself.
• A public library is considering a new computer system to help
administer book loans. Who are the stakeholders in such a
project? What may be some of the objectives of the project?
How would you practically measure the success of the
project?

END
• Thank you

CSIT 310
Design Project
Session 2 – Project Selection

2016/2017 – 2017/2018
Session 2
Project Selection
2016/2017 – 2017/2018
Learning outcomes
• Understand how a project must fit (align) with
organisational objectives
• Describe the concepts of programme
management and portfolio management
• Explain the project management perspective on
objectives, scope, stakeholders and stakeholder
value
• State the main contents of a feasibility study

Reasons for IT investment
• Survival
• Improved efficiency and/or effectiveness
• Competitive advantage
• External factors
(for example, legislation)
• Changing organisational structure

(for example, mergers)

Management of IT investment
• Programme management
• Project portfolio management

Allocation of IT budget
• Existing IS for ongoing operations and
maintenance
• Existing projects for ongoing agreed work
• Existing IS for system improvements
• Existing projects bidding for further new
development
• Project proposals

Setting up a project
• Selecting a project proposal
• Establishing a business case
• Business case
• Commencing the project

• Project charter or contract
• Scope statement
• Initial project plan

Project Management Lifecycle
Select Determine
Commence Manage Close Evaluate
Project Business
Project Project Project Project
Proposal Case
Project Charter
Project Evaluation
(or Project Contract), Final Project
Business Case &
Scope Statement & Report
Lessons Learnt
Initial Project Plan
Deliverable Deliverable Deliverable Deliverable
Carry out Systems

Feasibility
Study
Development
Lifecycle
Adapted from
Feasibility
Deliverable
Information System
Deliverables
Marchewka 2003
Study Documentation
Project proposal selection
Establishing a project’s contribution to the
organisation’s objectives:
• SWOT analysis
• Balanced Scorecard

SWOT analysis
Strengths Weaknesses
Opportunities Threats

The Balanced Scorecard
Kaplan and Norton 1996
Financial
How should we appear to

our shareholders?
Customer Vision Internal

and Business Process
How should we appear to Strategy What business processes
our customers?
must we excel at?
Learning & Growth

How will we sustain our
ability to change and
improve?

Feasibility study
• Perceived need for change
• Product/system interfaces
• Alignment with organisational
strategy/objectives • List of stakeholders
• Aim of proposed project • Potential benefits and estimated
• Objectives for the proposed project costs
– Benchmark levels (existing levels)
– Target levels • Proposed solution(s)
• Analysis of the external • Technology considerations
environment
• Product/system scope • Staff availability
– Functionality
– Levels of objectives • Dependencies, issues,
– Deployment within organisation assumptions and risks
• Current business process(es) and • Outline project plan
proposed changes
• Current IS and proposed changes • Summary of financial information
• Recommendations
Identifying the project aim
A project should have one major aim and several
objectives supporting the aim.
For example:
To improve our customers’ experience of ordering
our products.

Identifying the stakeholders
Any person or group that will be affected by the
system directly or indirectly.
For example:
• End-users
• Managers
• Systems administration
• Maintenance
• Testing
• Suppliers

Establishing stakeholder value
• What are the potential benefits?
• What could be done to achieve greater benefit?
• Which stakeholders could potentially benefit?
• Are any other projects impacting the benefits?
• Are the benefits greater than the costs?
• Are there any mandatory changes (for example,
legislation)?
• How will the benefits be measured?

Determining project scope
Determine what is included in the project and what is
not.
Scope can be defined as ‘the work the project has to
do’.
Establishing the scope includes consideration of:
• Functionality
• Levels of objectives
• Extent of the deployment within an organisation
Benefits, costs and timescales are linked to the
project scope.

Project Triangle
Financial Schedule
Budget
Scope
The financial budget and the time schedule together with the project scope
form the project triangle. Tradeoffs can be made amongst the three.

System interfaces
Identify all the interfaces with other systems
Establish the key data being passed across the interfaces
Look for ‘natural’ boundaries
Consider if there is any benefit in altering existing interfaces
Determine if any other projects are within the interfaces

Identifying the project aim
A project should have one major aim and several
objectives supporting the aim.
For example:
 To improve our customers’ experience of ordering
our products.
 To develop and evaluate an artificial neural network
to predict stock market indices

Identifying the project objectives
• Project objectives specify the success criteria

for a project
• Project benefits and costs are dependent on
the levels set for the objectives

Objective Hierarchy supporting an Aim
Aim
Objective A Objective B Objective C
Objective A.1 Objective A.2 Objective C.1 Objective C.2
Objective C.1.1 Objective C.1.2

Example of an Objective Hierarchy
Aim: - Quality Requirements only
Improved Web
Interface for
Customers
Customer
Usability Availability
Satisfaction
Product Customer
Information Feedback
Maintainability Reliability
Problem Information
Resolution Updating

SMART objectives
Doran 1981
• Specific
• Measurable
• Assignable
• Realistic
• Time-related

Objectives as success criteria
SMART objectives provide:
• A target to aim at
• The responsibility for ensuring and monitoring
that the targets will be achieved
• A point of reference
• Proof of agreement that can be used as proof of
achievement at the point of delivery

Example of a SMART objective
“The average time for a customer order of a single

order item to be input by an existing customer
will be reduced from 2 minutes down to 1 minute
by the end of November 2007”
Rather than “The time taken for customers to place orders

will be significantly improved.”
- How would you decide if the project was successful with
such an ambiguous objective?

Communicating with senior
management
Ensure you discuss the feasibility study with
senior management
Identify who is providing the budget for the project
Check the project is aligned with the organisation’s strategy
Determine if proposed functionality and deployment

within the organisation is correct
Obtain agreement to the project’s objectives
Discuss the stakeholder value and project costs

Selecting a student project topic
• Sources of Ideas
– Personal Interest
– Lecturers
– Books, Journals and Magazines
– Talk to others, departments, friends etc

Writing Your Proposal
Background
Defining the Problem
Aim
Objectives
Scope and Limitations
Proposed Content

Summary
• Reasons for IT investment
• IT investment management
• Proposal selection
• Contents of a feasibility study

END
• Thank you.

CSIT 310
Design Project
Session 3 – Research Methods

2016/2017 – 2017/2018
Research methods

Learning outcomes
• Outline the different research philosophies (postpositivism,
constructivism, advocacy and pragmatism)
• Understand the different research approaches (quantitative,

qualitative and mixed methods)
• Describe the different research methods including

experiment, survey, case study, action research narrative,
grounded theory and ethnography
• Understand the different data collection methods including

sampling, secondary data (documentation, survey and
multiple sources), observation, questionnaire and interview

Research process ‘onion’ Modified from Saunders et al 2000
Research Research
question philosophy
Research
Choice of
approaches
research Postpositivism
question Research
Quantitative methods
(Deductive)
Experiment
Survey
Sampling Case
Secondary data Cross study
Observation sectional Action Mixed Pragmatism
Questionnaire research methods
Interview Longitudin
al Grounded
theory Time
EthnographyNarrative horizons
Qualitative (Inductive)
Advocacy
Data
Constructivism collection
methods

Research design
Research philosophy
Objectives Research question
Chapters 2 & 3
‘Why’ Hypotheses
•Aim
•Objectives
Research strategy:
Strategy •Research approach
Chapter 3
‘What’ •Research method(s)
•Data collection method(s)
Tactics Research project plan

Chapters 5 & 6
‘When’
The research process
1) Identify your research problem (the research question)
2) Define its problem and its boundaries
3) Consider your research philosophy
4) Formulate your aim and objectives
5) Establish your research strategy

i. Determine your research approach
ii. Decide on your research method
iii. Decide your appropriate data collection methods
6) Produce your research project plan
7) Conduct research and gather data (data collection)
8) Analyse the data (data analysis) and evaluate the findings
9) Write up the results

The research question
“A research question is a way of explaining as
sharply and pithily as possible to yourself exactly
what you are going to research and what you
wish to find out.” (Birley and Moreland 1998)
A research question is often supported by one or

more hypotheses.

Example of a research question and
hypotheses
Research Question:
What factors influence successful student projects?
Hypotheses:
• Good working knowledge together with use of a
project management application is essential
• Keeping a very detailed journal is beneficial
• Reducing the amount of learning about new
technology is beneficial

Research philosophies
• Postpositivism: this is taking a scientific stance. You can
test your hypotheses using experiment, survey or
observation. Facts are universal truths independent of time
or context
• Constructivism: knowledge is viewed as encompassing
beliefs, principals, personal values, preferences, social
context and historical background. You don’t know in
advance what issues are going to be raised and the
findings will emerge out of your analysis
• Advocacy: constructivism is not sufficient - there should
be an ‘action agenda’ for change with change actually
being brought about (Creswell 2003)
• Pragmatism: the problem is the most important concept
and more than one philosophical stance can be taken - any
research method can be used to contribute to the findings

Research approaches
• Quantitative: takes a postpositivist approach and
uses research methods such as experiment and/or
survey to collect quantitative data (that is
measurements in the form of numbers)
• Qualitative: takes a constructivist approach tending

to use research methods such as case studies,
grounded theory and ethnography to collect
qualitative data (that is non-numeric descriptions)
• Mixed methods: takes a pragmatic approach and

can collect both quantitative and qualitative data

Research methods
• Experiment
• Survey
• Case study
• Action research
• Implementation research
• Grounded theory
• Narrative
• Ethnography

Experiment
• Testing a hypothesis
• Experimental and control groups
• Pre-test and post-test
• Statistically significant results

Survey
• Collecting data from a sizeable population
• Used to identify generalised features or trends
• Can survey individuals, documentation or
organisations
• Can be carried out by questionnaire, interview or
observation
• Can be face-to-face or not (for example by e-
mail)
• Sampling size is crucial

Case study
• In-depth analysis of one or more cases of an
event, an activity, a process or an individual in its
real-life context over a period of time
• Difficulties in controlling variables
• Generalisation can be difficult
• Use of historical information only means it is a
‘case history’

Action research
Researcher takes a role in the task being
researched and can change or influence in
some way the outcomes of the task
For example, being part of a team specifying

requirements and carrying out research on some
aspect of requirements specification being used
by the team and modifying the requirements
specification process being used in the light of
the feedback obtained

Implementation research
• Can be viewed as a special sort of action
research
• Proceed as follows:
– Collect data beforehand
– Devise and implement a solution
– Collect data to show improvement
– Consider if any other alternative designs would have been better
• Generalisation can be an issue

(perhaps try to implement the same software in more than one location)

Grounded theory
• Generation of theory from data - constructing
theory rather than testing theory - there is no
preconceived theory in place
• ‘Grounded theory’ because the theory is derived
from reference to the data collected (grounded
in the data)
• You build hypotheses from the data collected
and then seek to test them out. Sampling other
groups to find out the similarities and the
differences

Narrative
• Storytelling: get people to recount their
experiences of an event or series of events
• Researcher rearranges the events into a
chronological sequence
• Three-dimensional enquiry space: the temporal,
the spatial and the personal-social (Wood 2000 quoting
Clandinin and Connelly)

Ethnography
• An anthropological approach: The researcher studies
an intact cultural group in its natural setting over a
prolonged period of time
• Focus is on how people interact and collaborate in
observable and regular ways
(Gill and Johnson 2002)

Data collection methods
• Sampling
• Secondary data
– Documentation
– Survey
– Multiple source
• Observation
• Questionnaire
• Interviews

Data collection
Collecting data can be expensive in terms of time and
effort
Ensure you know:
– What data you need to gather
– What you will do with the data once you have gathered it
– Whether this is the best technique for gathering this sort
of data

Sampling
• Use sampling when it is not practical or
necessary to use the entire population of interest
• Two main types of sampling technique:
– Probability (representative - you can make statistical
inferences and generalise to the entire population)
– Non-probability (judgmental)

Secondary data
• Advantages: the data has already been
gathered by someone else, so information is
available cheaply (not always!) and rapidly
• Disadvantages: the data probably has been
collected for a different reason and you don’t
have access to the original source
• Three types:
– Documentation
– Survey
– Multiple source (the information has been compiled
from more than one source)
Observation
• Expensive in terms of time taken to make
observations
• Problems of making the observations
– Permission to make the observations
– Hawthorne effect
• Can be used to crosscheck data obtained using other
methods

Questionnaire
Advantages:
– They achieve wide coverage
– They are fast, in terms of reaching a large or
geographically dispersed group
– They are relatively cheap to produce and administer
to a large group
– They are standardised, ensuring identical questions
are asked of all subjects
– They can be anonymous, if that is desired, which
encourages full and honest answers
– They are suitable for extending data collection beyond
a set of interviews

Questionnaire
Disadvantages:
– They need to be carefully designed, and this requires
specialist skills
– Their design can be time-consuming
– They are normally subject to poor response rates (a typical
return rate is in the region of 10%)
– You can’t check or validate the results unless the replies
are named
– You are only analysing the results of those who bothered to
return the forms. There might be bias - you cannot assume
that they are typical of the whole group
(for example, if carrying out an organisational survey are the
respondents more likely to be happy or unhappy with the way things
are in the organisation?)

Interviews
• Types of interview:
• Structured
• Semi-structured
• Unstructured
• Can interview:
• One-to-one
• Groups
• Focus groups

Data collection and analysis
• Longitudinal versus cross-sectional data
• Access to data
• Ethics
• Confidentiality and trust

Data collection and analysis
• Reliability
• Validity
– Measurement validity
– Internal validity
– Generalisability or external validity
(Use of triangulation)
• Bias
– Researcher bias
– Respondent bias

Summary
Resign design:
• Research question
• Research philosophy
• Research strategy
– Research approach
– Research method(s)
– Data collection method(s)

END

CSIT 310
Design Project
Session 4 – Managing progress and change

2016/2017 – 2017/2018
Learning outcomes
• List the main project deliverables
• Outline the different types of testing
• Explain some of the issues associated with

managing change
• Discuss configuration management
• Describe two types of project management

review

Principles of Management
• A manager can control 4 things:

Resources (can get more dollars, facilities, personnel)
Time (can increase schedule, delay milestones, etc.)
Product (can reduce functionality - e.g. scrub requirements)
Risk (can decide which risks are acceptable)
• Approach (applies to any management)
Understand the goals and objectives
quantify them where possible
Understand the constraints
• if there is uncertainty, use probability estimates
Plan to meet the objectives within the constraints
Monitor and adjust the plan
Preserve a calm, productive, positive work environment
• ➜ Note:
• You cannot control what you cannot measure!

Session structure
– Stages of systems development
– Requirements specification
– Verification and validation (V & V)
– Testing
– Delivery to operations
– Issues associated with managing change
– Project deliverables
– Configuration management
– Project reports
– Management reviews

Project lifecycles
Manage the project
Project management lifecycle
Project management processes
Modify the system

Systems development lifecycle
Systems development processes
Run the system

System Lifecycle
Operational processes
including working practices
Project Start Project End

Project management process groups
Project Management
Processes (PMBOK Guide 2004)
Iteration
Monitoring &
Initiating Planning Executing Closing
Controlling
Processes Processes Processes Processes
Processes

Project management process groups
Project Management (PMBOK Guide 2004)

Processes
Iteration
Monitoring &
Controlling
Processes
Develop Project Develop Project Monitor & Control Close Project
Charter/Contract Management Plan Direct & Manage Project Project Work
Execution Contract Closure
Scope Definition & Change Control
Planning Quality Assurance
Scope Control
Create Work Schedule Control
Breakdown
Cost Control
Structure (WBS)
Quality Control
Quality Planning
Risk Monitoring
Risk Management & Control
Planning
All material presented in this course is based on the Performance
book by D. Dalcher and L. Brodie Successful IT Reporting
Deliverables of process groups
(PMBOK Guide 2004)
Project Management
Processes
Iteration
Monitoring &
Controlling
Processes
Project Project Management System Deliverables Accepted System Final Project Report
Charter/Contract Plan Deliverables
Work Performance Post-Delivery
Project Scope Information Requested Changes Review (PDR) Report
Statement Approved Change Requests
Requested Changes
Work Breakdown Rejected Change Requests
Structure (WBS) Corrective Actions Corrective Actions
Project Schedule
Preventative Actions
Cost Management Plan
Quality Control Measures
(Project Budget)
Performance Reports
Quality Management
Plan Business Review Reports
All material presented in this Risk Management
course is based on the
book by D. Dalcher and L. Brodie Successful
Plan IT
Systems Development
Processes
Iteration
Feasibility Requirements Functional Delivery to

System Design Coding Testing
Study Specification Specification Operations

Systems Development
Processes
Iteration
Feasibility Requirements Functional Delivery to

System Design Coding Testing
Study Specification Specification Operations
Deliverables:
Feasibility Requirements Functional System Design Source Code Test Plans Implementation Plan
Study Specification Specification Screen Layouts Test Data Installation Scripts
Test Reports User Manuals
Working Practices

From Chapter 2
Feasibility study
Perceived need for change Product/system interfaces
Alignment with organisational strategy/objectives List of stakeholders
Aim of proposed project
Potential benefits and estimated costs
Objectives for the proposed project
Benchmark levels (existing levels) Proposed solution(s)
Target levels
Technology considerations
Analysis of the external environment
Product/system scope Staff availability
Functionality
Levels of objectives
Dependencies, issues, assumptions and
Deployment within organisation risks
Current business process(es) and proposed Outline project plan
changes
Summary of financial information
Current IS and proposed changes
Recommendations

Requirements specification
Requirements elicitation
Communicating with the stakeholders in order to
identify/confirm requirements
Requirements analysis
Establishing how the requirements information from the
stakeholders ‘fits’ together
Requirements documentation
Capturing the requirements information in a structured way.
A requirements management application (for example,
DOORS) can be used

Requirements
Functional requirements
Capture the required functionality – what the system is expected
to do - and can be documented as functional descriptions or by
using use cases
Non-functional requirements
Express the system properties and constraints. They include:
• Industry quality standards
• Quality requirements (for example, usability, security, availability and
maintainability)
• Workload capacity requirements
• Design constraints
Note the quality requirements express the project success criteria.

Quality requirements should be measurable
(See Chapter 2, the section on ‘The role of success criteria in
projects’)

Example of a functional requirement
Statement of a functional requirement:
“Logging requests & appeals; requirements

associated with the capture of information about
applicants, [Ed. Requests for Information] RFIs
and appeals. This also includes the effective
handling of the RFI including searching for
requests by the same applicant, categorising the
request against subject lists / taxonomy;
searching the public authorities own disclosure
log to determine if the information has already
been released; and searching for similar
requests.”

Example of a functional requirement ….continued
This functional requirement is then decomposed into its elements

and captured. The Logging Application functionality is stated
as follows:
ID Description Priority
F-LA-01 The user shall be provided with a search facility to
determine if the applicant already exists in the system.
HD
If the applicant already exists the user may need to
update his or her details.
The system shall allow details of any new applicant
F-LA-02 E
making an RFI to be captured.
(See Appendix A for recommendations on information
that should be recorded)
Note “HD” stands for ‘highly desirable’ and “E” stands for
‘essential.’
A third category of “D”, ‘desirable’ also exists.
Example of a non-functional requirement
- Industry quality standards
ID Description Priority
N-ST-03 The system shall comply with the UK Government
Data Standards Catalogue (GDSC) that specifies
E
standard format and validation rules for those
information types indicated in Appendices A, B and
C.
N-ST-04 The system shall comply with the National
Archives’ Requirements for Electronic
HD
Records Management Systems, 2: Metadata
Standard.
N-ST-07 If the system uses an underlying relational
database, it must conform to the SQL standard
E
ISO/IEC 9075.
From www.foi.gov.uk/map/gusv4contents.htm

Specifying quality requirements (non-functional requirements)
using metrics Tom Gilb’s Planguage
Tag: <Name of quality requirement>.
Scale: <Scale of measure giving the units of measure>.
Meter: <The method to be used to obtain the measurements>.
Benchmarks:
Past [When, Where, If]: <Past or current level> ← <source of information>.
Record [When, Where, If]: <State of the art level> ← <source of information>.
Trend [When, Where, If]: <Prediction of future rate of change> ← <source of information>.
Targets:
Goal [When, Where, If]: <Planned target level> ← <source of information>.
Stretch [When, Where, If]: <Motivating target level> ← <source of information>.
Wish [When, Where, If]: <’Dream’ target level – not budgeted> ← <source of information>.
Constraints:
Fail [When, Where, If]: <Level at which project ceases to be a success> ← <source of
information>.
Survival [When, Where, If]: <Level at which project survival starts to be threatened> ← <source
of information>.

Example of a language quality requirement
Part of a hierarchy of Usability requirements:
Usability.Efficiency.Task Completion Time:

Scale: The average time it takes in minutes for
a defined [User Type: Novice User,
Experienced User] to carry out and complete a
defined [Task].
Meter: Analysis of the transaction processing
journal log.
Past [January 2007, Support Desk,
User Type = Experienced User,
Task = Entering a customer phone request for
support]: 5 ← Support Centre Manager.
Goal [June 2007]: 3 ← Support Centre Manager.

Verification and Validation
Boehm’s definitions 1981
For Verification (from the Latin, veritas,

‘truth’):
• Are we building the product right?
• Does the product correspond with its
specification?
For Validation (from the Latin, valere, ‘to be

worth’):
• Are we building the right product?
• Is the product fit for “its operational mission”

Verification and Validation
Verification
– Unit testing, interface testing, function testing and system
testing
– Management progress reviews
– Technical reviews
Validation
– User acceptance testing
– Management business reviews

Testing
• Unit testing (component testing)

• Integration testing
• Function testing
• Systems testing
• User acceptance testing
• Field testing (field trialling)

Delivery to operations
• Delivery of system software
• Documentation
– Description of delivery including change control
information
– An installation script
– User manual
– Changes to working practices

Working with end-users
• Authorisation
• Security • Risk to business
• IT experience
• Work pressure
• Existing working practices
• Daily work pattern
• IT compatibility
• Business culture
• Business jargon • Real data
• Parallel running
• Dress code
• Retry attempts
• Access to the building

Reducing people issues associated
with change
• Find a business champion
• Include the workers in the design and development
• Keep communicating about the project’s progress
• Keep reiterating the business reasons for the
project
• Provide adequate education and training
Marchewka 2006 quoting Leslie Jaye Goff

on ‘Change Management’ in Computerworld Feb 14, 2000

Project deliverables
• Both project management and systems development
deliverables
• Have to conform to relevant standards
• Many different types of deliverable
(for example documents, models and software)
• Evolutionary deliverables?
• Cost of deliverables
• Distribution of deliverables
• Security and backup
• Use of appropriate change control

Artifacts (System Documentation) Walker Royce 1998
Management Set
Planning Artifacts Operational Artifacts
1. Work breakdown structure 5. Release descriptions

2. Business case 6. Status assessments
3. Release specifications 7. Software changes
4. Software development plan 8. Deployment documents
9. Environment (Tools, etc.)
Systems Development Set
Design Set Implementation Deployment Set

Requirements Set
Set
1. User
1. Vision document 1. Design model(s)
deliverables
1. Source code
2. Requirements 2. Test model
2. Executable
model(s) 2. Test files and
software
3. Software test data
architecture
3. Installation
description
scripts

Systems documentation and other deliverables - Part 1
Deliverable Structure Standards Approval Needed People Resources

By Required
Business case Document Organisational Sponsor Business consultant

standards and IT and/or project
standards manager, & sponsor
Project charter & Document IT standards: Sponsor Project manager
project plan project plans
Technology & Document IT standards Project manager & Project manager &
organisational sponsor sponsor & users
assessment
Requirements Document IT standards: Sponsor & project Systems analyst &
specification requirement manager sponsor & users
specification
Functional Document IT standards: Sponsor & project Design team
specification Functional manager
specification
All User interface

material Prototype
presented in this course is based on the User interface Sponsor Design team & users
book by D. Dalcher and L. Brodie Successful IT guidelines
Systems documentation and other deliverables - Part 2
Deliverable Structure Standards Approval Needed People Resources

By Required
Testing plan Document IT standards: Project manager & Testers
testing testing manager
Testing results Document IT standards: Project manager & Testers
testing testing manager
Change management Document User standards Sponsor & project Systems analyst &
& implementation & IT standards manager project manager &
plan users
User manuals Document User standards Sponsor Documentation
& IT standards writers
Training plan Training class Training Sponsor Trainers
standards
Final project report Document IT standards Sponsor Project manager &
sponsor
Project evaluations Document IT standards Project manager & Project team
& lessons learnt IT management
Documentation standards
• Industry standards
• Project management method standards
• Systems development standards within the
organisation
• Documentation standards
• For student projects - any additional academic
documentation requirements?
Concerned with both Content and Layout
Always ask what documentation standards apply and if
any Templates exist

Variations in documentation
• Be aware of the organisational culture regarding
documentation
– Detailed or ‘light’
– Upfront or after implementation
This can also impact you in the amount of information

available for you to read up on about a system and it
impacts ease of maintenance

Configuration management
• Deliverable name
• Authorisation status
• Authorisation authority
• Author/originator
• Date last modified
• Quality level
• Version number
• Variant number
• Readership
• Configuration control (‘Build’ information)
• Change control information

Standards for document change control
• Document title
• Document filename
• Document storage
• Author’s name
• Version
• Date last modified
• Status (Draft / Inspected / Authorised)
• Authorised by
• Changes (Brief descriptions of changes made)

Project management reporting
• Status reports
• Progress reports
• Forecast reports

Project management reviews
• Progress reviews
Regular meetings reporting progress against plan and
discussing/resolving any issues
• Business reviews
– Less frequent meetings to consider if the project is doing
the ‘right thing’ for the organisation
– Linked to contractual points: ‘Go / No Go’ decisions

Summary
• Considered certain aspects of systems development
from a project management perspective:
– Requirements specification
– Testing
– Delivery to operations
– People and change management
– Standards for deliverables
– Project management reviews
• The aim is to help you consider these aspects with
regards your student project

END

CSIT 310
Design Project
Session 5 – Project planning

2016/2017 – 2017/2018
Learning outcomes
• Produce a work breakdown structure (wbs)

• Construct a project activity network diagram
• Analyse a project’s critical path
• Discuss the use of project management applications

Structure of the Session
• PMI’s project time management processes
• Project planning process
– Provide a statement of work (SOW)
– Create a WBS
– Develop a project schedule
Activity network diagrams
– Activity on node (AoN)
– Activity on arrow (AoA)
• Gantt charts
• Use of project management applications

Project time management processes
(PMBOK Guide 2004)
• Activity definition
• Activity sequencing
• Activity resource estimation
• Activity duration estimation
• Schedule development
• Schedule control

The project planning process
1. Develop a statement of work (SOW)

2. Identify the project tasks
3. Create a work breakdown structure (WBS)
4. Identify the milestones
5. Estimate effort/duration of each task
6. Identify the resources required for each task
7. Create the project schedule

Identify the project tasks
• Produce an initial task list by using one or more of
the following:
– Project lifecycles
– Functional specialisation
• Organisational roles
• Knowledge areas
– Project objectives
– Information from past projects

Create a work breakdown structure
(WBS)
A breakdown of the project tasks in a hierarchical tree
structure
A typical six-level WBS would have the following levels:
– Total programme
– Project
– Task
– Sub-task
– Work package
– Effort

Work package
Each work package described with the following
information:
– What work needs to be done
– Who is responsible for carrying out the work
– What deliverables and milestones will result
– Dependencies on other tasks
– Effort/duration (or start and completion dates)
– How the work is to be carried out (methods to be
used)
– The hardware, software and tools required
– Any special skills required

Example of a WBS
Project Tasks
Requirements System Delivery to

Coding Testing
Specification Design Operations
3000 4000
1000 2000 5000
Requirements Requirements Unit & Integration Function & System User Acceptance
Testing Testing Testing
Capture Analysis
4100 4200 4300
1100 1200
Interviews 1110
Observation 1120
Documentation 1130

Example of a WBS
Project box,
Project Tasks
node or root node
Nodes or
tasks
Requirements System Delivery to

Coding Testing
Specification Design Operations
3000 4000
1000 2000 5000
Requirements Requirements Unit & Integration Function & System User Acceptance
Testing Testing Testing
Capture Analysis
4100 4200 4300
1100 1200
Interviews 1110
Sub-tasks
Observation 1120
Terminal node (no further
Documentation 1130
decomposition to be carried out)
Numeric format for a WBS
1000 Requirements specification

1100 Requirements capture
1110 Interviews
1120 Observation
1130 Documentation
1200 Requirements analysis
2000 System design
3000 Coding
4000 Testing
4100 Unit & integration testing
4200 Function & system testing
4300 User acceptance testing
5000 Delivery to operations

Identify the milestones
A milestone occurs on the completion of a task that

produces a deliverable that significantly contributes
to the project’s progress (for example the system
design)
Milestones are events, not tasks
Project funding can be linked to milestones

Estimate effort/duration of each task
• A bottom-up approach by adding together the effort
for all the tasks
• Measured typically in person-days or person-hours
• Measures the time needed to complete a task, not
the elapsed time (which measures the time that
elapses from starting a task to completing it)

Effort estimation table (EET)

Note trailing ‘_’ for lowest level tasks with no sub-tasks.
Identify the resources required for
each task
Resources include:
– People
– Equipment
– Facilities
– Services
– Materials
For example software, hardware, office space and staff

Create the project schedule
Tasks to create the project schedule:
– Establish the task dependencies
– Identify the critical path
– Examine the task scheduling
– Allocate resources
– Set project time data
– Establish project completion date
– Establish cost schedule
– Get customer approval and project team member’s
agreement to the schedule

Activity network diagrams
• Show the sequencing relationship among tasks
• Two types:
– Activity-on-Node (AoN)
– Activity-on-Arrow (AoA)

Activity-on-Node (AoN) diagrams
An AoA node:
A Earliest start date

A B
B Duration
Task name
C Latest start date
C D D Slack

Linked nodes
1 + 40 = 41
1 40 41 20
Literature Literature
search review
C D C D

Multiple dependencies
60 10 70 30
System Coding
design
C D C D
60 5
Interface
design
C D

Depicting milestones in an AoN diagram
16 2
From page x of milestones

User acceptance
AoN diagram testing M1
1 15 18 2
Produce
User training
user training M2 M3
manual
3
20 15
Field testing
M4
35 5
Software rollout
Calculating the latest start date
75 - 10 = 65
60 10 70 30
System Coding
design
65 D 75 D
60 5
Interface 75 - 5 = 70
design
70 D

Calculating the ‘slack’
60 10 70 30
System Coding
design
65 5 75 5
60 5
75 - 70 = 5
Interface
design
70 10

Activity-on-Arrow (AoA) diagrams
An AoA node:
N Node Id
E E Earliest time
N (optimistic, shortest time)
L L Latest time (pessimistic,
longest time)

Simple AoA diagram
Observation 10
5
1 4
8 5 days 13

An example of an AoA chain
Requirements Systems
analysis design
1 2 3
10 days 15 days

Branching
B
3
A C
1 2 4
12 5

Merging
1
D
F
3 4

Dummy node
Dummy node
3
B
3
A C D
1 2 4 5
12 5 3

Single start and end nodes
Start node C G
4 6 9
2 4
D E
A 1 5 H
5 3
B F I
1 5 7 10
4 5 2
0 J
8
2 L
3
End node
K
3 8
4
Representing the critical path in AoN diagrams
Use of
double arrows to
From page z of mark critical path
AoN diagram
1 2 20 15
Establish
field testing Field testing
plan M4
0
18
35 5
Software rollout

Critical path calculation
C G
2 4 7
2 4
E
A D 0
1 5 H
5 3
B F I
1 3 5 6
4 5 2

Calculating the critical path
C G
2 4 7
2 4
E
A D 0
1 5 H
5 3
B F I
1 3 5 6
4 5 2
Path Duration
A, C, G 11
B, D, G 9
B, E 9
B, F, H 12
B, F, I, (Dummy) 11
Critical path identified
C G
2 4 7
2 4
E
A D 0
1 5 H
5 3
B F I
1 3 5 6
4 5 2
Use of bold arrows

to mark critical path

Task precedence table

Tasks against project timescales
TD
Using earliest
start dates
SQL M
R SD ID C T1 T2 T3 D
Day 1 5 10 15 20
TD
SQL
Using latest
start dates
M
R
SD ID C T1 T2 T3 D
Initial resource allocation
Omar
R M T2 T3
Day 1 5 10 15 20
Over allocation
of resources
TD
Jane
SQL
SD ID C T1 D
Floated resource allocation
Omar
R M SQL TD M T2 T3
Day 1 5 10 15
Jane
SD ID C T1 D
Day 1 5 10 15

Resource smoothing
The APM defines resource smoothing as the
“scheduling of activities, within the limits of their
float, so that flucuations in individual resource
requirements are minimised.
…the project completion date may not be delayed.”
www.apm.org.uk/RtoT.asp/

Resource levelling
The APM defines resource levelling as the “scheduling
of activities so that predetermined resource levels
are never exceeded.
Note: this may cause the minimum overall or specified
project duration to be exceeded.”
www.apm.org.uk/RtoT.asp/

Mapping the project schedule onto
time
• Set project start date
• Set project weekly hours for resources
• Establish project completion date
• If necessary, adjust project completion date (for
example by using extra resources, more experienced
staff and better technology)
• Establish cost schedule
• Get customer approval
• Get project team members’ agreement to the
schedule
Gantt charts
• Excellent way to present your project plans
• Plot the activities/tasks against calendar dates
• Can show parallel activities
• Can show resource allocation
• Can also show project progress

Example of a Gantt chart
Jan 1 2007 Jan 8 2007 Jan 15 2007

Jan 22 2007
Task Name Duration SMTWTFS
SMTWTFS SMTWTFS SMTWTFS SMTWTFS
1 - Project ABC 20 days
2 - Requirements specification
4 Interviews 3 days
5 Observation 2 days
6 Documentation 2 days
7 Requirements analysis 2 days
8 Requirements completed 0 days
9 System design 2 days

10 Coding 3 days
11 Coding completed 0 days
12 - Testing
13 Unit & integration testing 2 days
14 Function & system testing 2 days
15 User acceptance testing 1 day
16 Testing completed 0 days

All material
17 presented inDelivery
this course is based on the
to operations 1 day
Adjusted Gantt chart
Jan 1 2007 Jan 8 2007 Jan 15 2007
Jan 22 2007
Task Name Duration SMTWTFS
SMTWTFS SMTWTFS SMTWTFS SMTWTFS
1 - Project ABC 20 days
2 - Requirements specification
4 Interviews 3 days Jane

5 Observation 2 days Jane
6 Documentation 2 days Jane
7 Requirements analysis 2 days Jane
8 Requirements completed 0 days
9 System design 2 days Jane

10 Coding 3 days Jane
11 Coding completed 0 days
12 - Testing
13 Unit & integration testing 2 days Jane
14 Function & system testing 2 days Jane
15 User acceptance testing 1 day Jane
16 Testing completed 0 days
17 Delivery to operations 1 day Jane
18 Project completed 0 days

Use of planning tools

Uses and Advantages of AoN and AoA diagrams
AoN Network Diagrams AoA Network Diagrams

Uses: Uses:
- Is used more typically in computing - Is used in engineering and
- Is utilised in project management construction
software applications
Advantages: Advantages:
- All the required information about an - There’s a logical resemblance to a
activity appears in one box bar chart
- Allows a greater variety of links and - Events are explicitly shown
various types of dependencies (for - Easier to check calculations manually
example finish-to-start lag) - Easier to find critical path
- Does not require dummy activities - Can be adjusted to show passage of
(and so keeps the number of activities time
to the real number)
- Better at representing relationships
with multiple precedents
book by D. Dalcher and L. Brodie Successful IT - Dummy activities can be used to
Summary
• The project planning process:
– Identifying tasks
– Creating a WBS
– Scheduling the tasks
• AoN diagrams
• AoA diagrams
– Identifying a project’s critical path
– Establishing a project completion date
• Gantt charts

END

CSIT 310
Design Project
Session 6 – Cost management

2016/2017 – 2017/2018
Lecture 2
Cost Management
2016/2017 – 2017/2018
Learning outcomes
• Understand the place of cost management within
project management
• Outline a process for cost estimation
• Describe COCOMO II and other methods used for
cost estimation
• Explain the use of earned value management (EVM)
for cost control

Software costs
• Direct costs for developing and maintaining software
• Indirect costs
• Operating costs

Direct costs
• Creating and updating the software requirements
specification and design specification
• Carrying out the coding and testing
• Ensuring software quality (for example reviews and
inspections)
• Software maintenance
• Purchasing bought-in software artefacts
• Project management

Indirect costs
• Development and test platforms (hardware, system
software and software tooling)
• Communications and collaboration platforms (e-mail
and intranets)
• Office space and administrative facilities

Operating costs
• The operating platform (hardware and system
software)
• Software costs (for the developed software)
• Installation and upgrade costs
• Training costs
• User costs (for example data entry)
• Quality costs (for example business costs due to
software errors)

Benefits
• Direct Benefits
• Assessable indirect benefits
• Intangible benefits

Relationship regarding costs between
project and users
Software users
Project
Development
funding
Development Operating costs

& maintenance Transfer cost
costs •software
- direct costs •training
- indirect costs •installation
On-going costs
for using software
& maintenance

Managing project funding
The project manager must:
• Produce credible plans showing funding
requirements
• Ensure stakeholders are not surprised with major
changes to plans or costs
• Keep stakeholders informed of progress at regular
intervals
• Alert stakeholders to any difficulties as early as
possible

Contracts
The project manager must ensure:
• Financial commitments by various stakeholders are
clearly stated
• Appropriate measures for dealing with non-payment
are present
• Where payments depend on deliveries, the
deliverables are well-defined with responsibility and
procedure for approving them clearly stated

Cost management processes
Cost
management
Cost Cost Cost

estimation budgeting control

Overview of how cost management fits into
the project processes
Feasibility Business case Software
study process
Requirements
monitoring Benchmarking
& scope
Technology
considerations
Planning Contract/
funding Service negotiation
& budget Cost estimation
Cost budgeting
Project Work monitoring

execution
Cost control
Contract/
Service monitoring

The cost estimation steps
Work Cost
breakdown breakdown
structure (WBS) structure
Software Software Software

design task cost
Software Software Software

size effort cost
Step 1 Step 2 Step 3

Step 1: Software size
Software size measured by:
– Code size
– Some aspect related to required functionality

Software size using code size
• Count the lines of code (LOC)
• There are different ways of counting lines.
For example:
– Source lines of code (SLOC) counts only the source lines
that are delivered (not test drivers, etc.)
– Delivered source instructions (DSI). An if-then-else
statement would be one SLOC but several DSI

Software size using code size
Problems:
• Comparing or aggregating different programming
languages
• New software development methods
For example:
• Use of models
• Automatic code generation
• Reuse

Software size based on functionality
Types of functionality-based metric What gets counted?
Function points Inputs, outputs, files and inquiries
Object points/Application points Screens, reports and modules
Use case points Use cases

Function point analysis (1)
First identify instances of the following function types:
– Internal logical files: any file created or updated by the
software
– External interface files: any file only read by the
software
– External inputs: a process allowing data to enter the
software, for example an input screen
– External outputs: a process allowing data to exit the
software, for example a report or display screen
– External inquiries: reads data from internal and
external files with no updating

Then decide the complexity of each instance
Function Type Complexity Weight
Low Average High

Internal logical files 7 10 15
External interface files 5 7 10
External inputs 3 4 6
External outputs 4 5 7
External inquiries 3 4 6
From Boehm et al (2000c)

Add the number of instances in each category and then
multiply by the relevant complexity weight
So if for the function type of ‘external interface files’

there are 3 instances of low, 4 of average and 6 of
high complexity, then
(5 x 3) + (7 x 4) + (10 x 6) = 15 + 28 + 60 = 103
Add together with all the values for the other function
types to get the unadjusted function point (UFP)
value

Adjust the UFP with a value adjustment factor (VAF). A
VAF reflects the overall complexity of the project and
is calculated from 14 system characteristics (such as
multiple sites and reusability). Each system
characteristic is given a score from 0 to 5. These are
added together to give a total degrees of influence
(TDI) value.
VAF = (TDI x 0.01) + 0.65

Total function points (FP) = VAF x UFP
Function points can be converted into development

effort in two ways:
– Directly using productivity rates
– Via conversion rates to lines of code

Productivity rates
You determine the productivity rates by experience. You need

to know the rate at which your organisation can code
function points. Then you can calculate software effort*
Software Effort = FP / Productivity Rate
For example: FP = 300 Rate = 6 FP/person-month
Then Effort = FP / Rate = 300/6 = 50 person-months
Multiply by the cost of a person-month to determine the
financial cost*
*Note software effort and software cost are Steps 2 and 3, so this slide is leaping ahead
somewhat, but it’s important to understand the two ways in which FP is used! (See
previous slide)

Conversion rates for FP to SLOC
(SLOC being a measure of software size)
Programming Average number of

language SLOC per UFP
C++ 55
Java 53
Visual Basic 5.0 29
Fourth Generation
Language 20
HTML 3.0 (Boehm et al 2000c quoting figures

15from Jones 1996)
Application points and
use case points
• Application points (formerly known as object points)

count higher level software items such as screens,
reports and modules. Otherwise similar to function
points
• Use case points are relatively new and due to their
wide range of interpretation there are difficulties
extending beyond “a relatively uniform group of
applications and practitioners”
(Boehm et al 2000c)

Step 2: Software Effort
“If 2 pretzel makers can make 444 pretzels in 6 hours,
how long does it take 5 pretzel makers to make 88
pretzels?”
(Enzensberger 2006)

Software effort calculation
As we have just seen using productivity
rates with function points:
Software Effort = FP / Productivity Rate
Or to express this more generally:
Software Effort = Software Size / Productivity Rate

Effort and Productivity
• Units for effort can be person-hours, person-weeks, person-

months or person-years
• Productive time. Have to allow for other things (for example
holidays, weekends, lunch, sick days, training and travelling
time)
• Overheads: How are management and administrative tasks
accounted for?
• People productivity varies:
– Some people more productive
– Experts in a task tend to be more productive than novices
– People have different levels of sickness and absenteeism
• Some tasks more difficult than others

Complexity
• Try using multiple categories to cater for the different

skill levels and different tasks
• Even further complexity due to ‘diseconomy of
scale’. Large projects will require more
communication and organisation. However
component-based development could require less…
• Solutions to these problems have been to use:
– Expert opinion
– WBS-based costing (or activity-based costing)
– Algorithmic approaches

Step 3: Software cost
• Once you have effort, then converting into cost is a
matter of knowing the standard cost
• However:
– People are on different pay scales (for example, project
manager, programmer and systems architect)
– Rates for the same job can vary due to industry and/or
location
– New recruits will require money to be spent on support
and training
• If we assume the more expensive workers are the
more productive, then there is some offset

Software estimation techniques
Software estimation techniques
Parametric Expertise Learning Dynamics Regression Composite-

model -based -orientated -based -based Bayesian
-based
COCOMO II
Wideband
COCOMO 81 Neural Abel- OLS
Delphi
SLIM Case-based Hamid- Robust
Rule-based
Checkpoint (Analogy) Madnick
WBS-based
SEER

Wideband Delphi
• Expertise-based cost estimation

• Introduced by Barry Boehm in 1970s
• Iterative
• Gather a group of experts
• The experts each give their estimate
• The results are tabulated.
• The experts discuss the tabulated results (Such
discussion only occurs with Wideband Delphi variant)
• The experts again each give their estimate
• And so on, iterating until there is a convergence of
views on an estimated value
WBS-based costing
• Sometimes known as activity-based costing
• Each task/activity in a WBS is individually costed
• Bottom-up technique starting from the lowest levels
of the WBS and aggregating upwards
• Can aggregate by using two types of WBS:
– Product WBS: aggregating according to the different
product modules
– Process WBS: aggregating according to the type of process.
For example aggregating by processes such as testing and
coding

COCOMO II
• Constructive Cost Model
• A parametric or algorithmic model
• Developed by Barry Boehm
• COCOMO 81 (COCOMO I) in 1981 for Waterfall model
• COCOMO II in 2000 for “evolutionary, incremental and
spiral models” (Boehm et al 2000c)
• COCOMO II also caters for very high level languages
(VHLLs), commercial off-the-self (COTS) software and
reuse through various extension models

COCOMO II extension models
(Boehm et al 2000c)
• COPSEMO: phase schedule and effort

estimation
• CORADMO: rapid application development
estimation
• COCOTS: COTS integration estimation
• COQUALMO: quality estimation (concerned
with defect introduction and defect removal)
• COPROMO: productivity estimation
• Expert COCOMO: risk assessment

COCOMO II’s three basic models
• Choice of model depends on the development stage:
– Application composition: for software developed using
prototyping usually in early stages of development. Uses
application points
– Early design: used during early stages when little is known
about the system design. It uses KSLOC or UFPs
– Post architecture: used during actual development and
maintenance of software. Uses SLOC or FP

Cost drivers and scale factors
• COCOMO II sets out a series of cost drivers and scale factors
impacting cost
• Values (known as effort multipliers (EM)) for the various cost
drivers and scale factors differ for the different models.
Default EM values are given by COCOMO II, but should be
calibrated by an organisation using feedback obtained from
their own project experience
• Cost driver and scale factor EM values are inserted into the
COCOMO II equations

Cost estimation tools
• Many cost estimation tools exist:
– COCOMO II
– CoStar
– CostModeler
– CostXpert
– KnowledgePlan
– PRICE S
– SEER
– SLIM
– SoftCost
Caper Jones (2005)
Cost estimation tools
“The commercial software estimating tools are far from perfect
and they can be wrong, too. But automated estimates often
outperform human estimates in terms of accuracy, and always
in terms of speed and cost effectiveness. However, no method
of estimation is totally error-free. The current best practice for
software cost estimation is to use a combination of software
cost estimating tools coupled with software project
management tools, under the careful guidance of
experienced software project managers and estimating
specialists.”
Capers Jones (2005)

Cost measurement
• Metrication within organisations
• Historical data
• Calibration
• Use of feedback

Summary
Cost management
• Cost estimation
– Establish software size (SLOC and FP)
– Establish effort (productivity rates)
– Calculate software costs
• Cost budgeting (PV)

• Cost control (EV and AC against PV)

Needs, Opportunities & Requested Changes
Overview of the
Requirements Requirements Functional cost management process
Specification Specification Specification and related processes
Create/Modify
Stakeholder Value/ Functional WBS
Potential Benefits Step 1 Specification
Step 2
Software Tasks Software Process
Establish
information
Software Size Establish Effort
Cost Effort Step 3 All Tasks
Estimation Quantity/
Software Size Calculate
Software Costs
Resource
Availability
Software Cost Estimates
Create/Modify Actual Costs (AC)
Schedule Report
Other Costs
Cost Cost
Budgeting Add Planned Control
Revised
Cost Estimates Schedule Cost Estimates,
into Schedule Earned Value (EV)
information,
Monitor & Control
Planned Total Budget Corrective Actions,
book by D. Dalcher and L. Brodie Successful IT Costs / & Updates to
Summary continued…
• Cost estimation methods
– Wideband Delphi
– WBS-based costing
– COCOMO II
• Cost control method

– Earned value management (EVM)

END

CSIT 310
Design Project
Session 7 – Leadership and Teamworking

2016/2017 – 2017/2018
Lecture 2
Leadership and Teamworking
2016/2017 – 2017/2018
Learning outcomes
• Discuss the importance of people factors in projects
• Explain the role of an effective project leader in an IT project
• Identify and explain the key factors in creating positive teamwork
• Discuss some ethical and cultural issues relevant to projects

People make the difference
30% of project success attributable to user involvement

and executive support
Standish Group’s Chaos Report (1994)

Factors influencing project failure (Yardley 2002)
Technical Failure Human Failure Process Failure

Lure of the leading edge Lack of executive support Absence of any project
management methodology
Poor technical design Lack of leadership Absence of any systems
development methodology
Technical solution to a non-technical Uncommitted project team Absence of any benefits
problem management methodology
Dependence on software packages Dysfunctional project team Failure to identify and
to satisfy requirements mitigate project risks
Lack of tools throughout Failure to manage third parties Failure to manage
development lifecycle requirements
Technology-led development Lack of a project ‘champion’ Lengthy project timescales
Lack of project ownership Insufficient testing
Stakeholder conflict ‘Big-bang’ approach to
computerization
Resistance to change
Hostile organizational culture
Inexperienced project managers

Lack of business justification
book by D. Dalcher and L. Brodie Successful IT Unclear or ambiguous business priorities
Teamwork
A Team is more than a group of individuals.
Project team members must have:

– A shared goal
– Commitment to each other within a project
– Willingness to learn
These are all values that the individuals have to adopt

Teamwork
Teams also need skills
Good teamwork needs:
• Expertise in the subject at hand
• Knowing how to work as a team
• Planning
• Conduct of good meetings
• Ability to manage logistics and details
• Gathering of useful data
• Effective analysis of the data
• Communication of the results and implementation of changes
Peter Scholtes (1996)

Teams within an organisational context
• A project team has to work within an organisational

context
• A project team could be formed with people from
one or more departments and from one or more
divisions. It could even be across more than one
organisation
• Handy (1978) calls organisations frequently setting
up teams across departments/divisions, “matrix
organisations”
• When teams are across more than one organisation,
developing good teamworking is more challenging

Project boards and steering committees
• A project team reports to a project board or a

steering committee
• The project board or steering committee consists of
senior management. They review the business
benefits and control the funding. They are
responsible for project ‘Go / No Go’ decisions. They
are also responsible for ensuring the project
governance

Project management
Three key roles held by one or more people:
– Champion
– Leader
– Manager

Specialist roles
In addition to the project management, project teams
need other specialists
• For project scoping:
– Business analysts, requirements analysts, market
researchers, report writers
• For development:
– System architects, web designers, database designers,
programmers, software testers
• For handover:
– Writers of user guides, technical support

Shaping the project team
Factors affecting who is assigned to a project team:
• Organisational culture
• Business sector(s)
• Leadership style
• Timelines
• Desired secondary outcomes
• Regulation compliance demands
• Available resources
• Anticipated team dynamics

Organisational culture
• ‘The way we do things around here’
• Edgar Schien (1980) identifies areas where culture
may manifest itself:
– Language
– Use of symbols
– Ceremonies
– Customs
– Methods of problem solving
– Use of tools or technology
– Design of work settings

Business sector(s)
• Consider how project teams would be formed:
• In higher education
• In IT consultancy firms
• On major construction projects
• In small software development enterprises

Leadership style
• Authoritarian
• Participative
• Delegative

Timelines
• Inelastic
• Elastic
• Probably worth also considering whether time-

pressured. Some staff work well under pressure,
others do not

Secondary outcomes
• Maybe there are other goals for this project?
– Staff training
– Customer relationship
– Pave the way for bigger contracts

Regulations
• Compliance with regulations is a strong determining
factor in team selection
• Many organisations and project management
methods have pre-assigned role descriptions. For
example, quality manager and testing manager

Resource availability
• Which staff have the required skills?
• Are the staff available to work on this project?

Influence of team dynamics
• Consider temperament clashes and differences in
personal working styles
• Meredith Belbin (1981) identifies the following team
roles:
– Resource investigators
– Co-ordinators
– Teamworkers
– Monitor/evaluators
– Shapers
– Completer-finishers
– Plants
– Implementers

Project teams relationship with the
customers
• Customer relationship management (CRM)
• Customers in project teams / impact of agile

methods demanding customer involvement

Customer relationship management (CRM)
Involves considering such things as follows:

• Do the opposite numbers (e.g. project leaders, sponsors, software
developers, systems integrators), know and respect each other?
Do they like each other? Do they acknowledge each other and
communicate with one another?
• Have the internal reporting structures changed on either side?
• Have the quality control systems changed on either side?
• Has everyone got the latest versions of order forms, sign-off
sheets, logos, etc?
• Are all contact addresses the same as last time?
• What history is attached to meeting attendance? Who is likely to
be there? Who is likely to change times/locations and why?
• Which business pressures should you factor in to project planning
(e.g. different accounting periods, sales conferences)

Project communication
More formal project communication is by means of:
– Meetings
– Reports

Meetings
• Meeting modes
– Coaching sessions
– Work-group meetings
– Review meetings
• Cultural differences in meetings
– To present decisions versus to reach decisions
– Approach to conflict
– Approach to politeness and etiquette
– Gender issues over equality of women
– Meaning of gestures

Written reports
• Some reports will be mandatory, others at the
project manager’s discretion
• Consider how the data for a report is collected. Can
be:
– Online forms viewable by all the project team
– Forms submitted by e-mail
– Simple e-mailed data
– Project manager discussion and form-filling

Ethics
• Human interaction
• Payments
– Bonuses
– Rules over hospitality
• Intellectual property rights (IPR)

– Who owns the work?

Working as a team
• Communication
• Support
• Conflict handling

Communication
Work by Hofstede, Trompanaars and Hampden-Turner
on national cultures identifies the following
dimensions:
– Power or equality
– Achieved status or ascribed status
– Individualism or collectivism
– Specific or diffuse
– Universalism or particularism
– Uncertainty avoidance or uncertainty tolerance
– Neutral or affective
– Long-term or short-term perspectives
– Time as sequence or time as synchronisation
– Masculinity or femininity

Communication
Myers-Briggs (personality) type indicators:
• extravert/introvert
• feeling/thinking
• perceptive/judgmental
• sensing/intuitive
Preferred style of communication:

• Visual
• Auditory
• Kinaesthetic

Support
• Involves the entire project team
• Ultimate responsibility is with the project manager
• The following can help:

– Good governance: formal project organisation stating
responsibilities and meeting/report structures
– Right set of team skills
– Coaching and mentoring

Conflict handling
• Personality clashes
• Working style clashes Already considered
earlier in this lecture
• Culture clashes
• Everyday tensions
• Professional disagreements

Summary
• Importance of people factors
• Key factors in teamworking
– Team selection
– Team dynamics
• Cultural issues
– Organisational
– National

END

CSIT 310
Design Project
Session 8 – Project Quality Management

2016/2017 – 2017/2018
Lecture 2
Project Quality Management
2016/2017 – 2017/2018
Learning outcomes
• Understand the importance of quality
management
• Describe the main processes of project
quality management and understand how
they relate to projects
• Describe several quality control techniques
• Understand the contribution of the major
quality experts to quality management
• Discuss quality standards and models

What is quality?
• Quality of design:
– Decide the level of quality required - characteristics of the
product or service such as grade of materials and performance
specifications
• Quality of conformance:
– The degree to which the design specifications are met or
‘conformance to requirements’
• Fitness for purpose:
– Means that the product can be used for the purpose it was
intended. Usually considered more rigorous than ‘fitness for use’

Different views of quality
• Quality as:
– A product-based quantity
– A user-based view
– A specification
– A value-based approach
– A transcendent property
– A continuous property

The cost of quality
• Cost of quality (COQ) includes all the costs
associated with quality-related processes
• Cost of quality factors:
– Prevention costs (includes quality planning,
technical reviews, test equipment and training)
– Appraisal costs (includes inspections and testing)
– Failure costs
• Internal failure costs (rework)
• External failure costs (helpline support and fixing customer
fault reports)

The cost of quality
Crosby (1980)
COQ = POC + PONC
Cost of quality (COQ)
Price of conformance (POC): price of ensuring
“things are done right the first time”. The sum of
prevention costs and appraisal costs
Price of non-conformance (PONC): the failure
costs

Cost to fix escalates as you move
towards field use
40 - 1000x
Relative cost to fix an error
82x
30 - 70x IBM
average
15 - 40x
10x
3 - 6x
1
Requirements Design Coding Development Acceptance Operation
Testing Testing
Project quality management
• Quality planning:
– Identifying the relevant requirements, quality procedures and
standards, and determining how a project will meet them. Must
have both product/system metrics and project process metrics
• Quality assurance:
– Carrying out the planned quality activities to ensure the project
delivers a quality product/service
• Quality control:
– Monitoring the project results to ensure they meet the relevant
quality standards. Outputs include quality control status reports,
rework and process improvements

Quality control methods
• Management reviews
Already discussed
• Testing
• Pareto analysis
• Control charts
• Walkthroughs
• Inspections

An example of a Pareto diagram
Number of defects reported over a given time period
(Note all percentages are rounded down)
200 185 100%
Cumulative Percentage
160 80%
142
120 60%
80 40%
40 30 20%
20
10
0 0%
Insufficient Missing Missing Missing Status Missing Target
Qualifier Data Source Benchmark Data Level
Information Data

An example of a control chart
Upper Control Limit
Violation of control limits
3σ
2σ
σ
Mean Time
σ
2σ
3σ
Lower Control Limit

Control charts
• Chance causes: tend to lie within the control limits -

only a one in a thousand chance of not doing so
• Special causes (assignable causes or sporadic
causes): controlled at the local or operational level.
Eliminating these means the process returns to its
controlled state. Identified by looking for patterns that
suggest non-random behaviour in the control chart.
Corrective actions are needed to remove special causes.
For example, can detect when manufacturing equipment
is becoming defective
• Common causes (endemic causes or chronic
causes): inherent in the process, only if the basic process is
altered will they change

Walkthroughs
• A walkthrough is a type of peer group review
• Informal and lasts 1 to 1.5 hours
• Purpose is to enforce standards, detect errors and
improve visibility of the material and overall system
quality
• Product author typically describes the structure and logic
of the material being reviewed
• A co-ordinator plans and organises the walkthrough
• An action list of problems and questions is generated
• Outcome is a decision about whether the material can be
accepted as it is or whether it needs revision and even a
further walkthrough
Inspections
• Carried out on written documentation
• Originally developed by Michael Fagan for use on
source code
• Now extended by Tom Gilb for use on earlier system
documents (requirements specifications and even
contracts)
• Also extended by Robert Mays (IBM) to support
continuous process improvement
• Gilb has moved focus from defect finding and fixing
towards sampling to determine quality (better to
rewrite than fix if a high number of defects)

Inspection
• Inspection must be economic
• Can be used for training about standards
• Does not replace testing, but can be argued to
find defects earlier
• Checkers are given roles
• Use rules and checklists to find ‘issues’
• Check against source and kin documents
• Author has final say if ‘issues’ are ‘defects’

Main Specification,
Overview of the Source Documents,
Kin Documents,
inspection process Rules
and Checklists
Process
Meeting
Specification Edit
Entry Planning Kickoff Checking Edit Exit
Meeting Audit
Strategy Statistics
Quality Checked
Main Specification,
Change Requests for
Source and Kin Documents
and Suggested Process
Improvements

Quality metrics
How can quality be expressed?
– Think back to session 2 and the discussion on success
criteria being picked up as project objectives
– Remember Doran’s SMART method
– Think back also to session 4 and the discussion about
quality requirements
– Earlier in this session under quality planning, we
mentioned product/system metrics and project process
metrics

Key contributors to the
quality movement
• Walter Shewhart
• W. Edwards Deming
• Joseph Juran
• Philip Crosby
• Kaoru Ishikawa

Walter Shewhart
• Encouraged managers to think about problem
prevention and process improvement
• Developed:
– The control chart (discussed earlier)
– The Plan/Do/Check/Act cycle for process
improvement

The Shewhart Cycle or Deming Cycle
Decide Actions Plan Actions

Needed
Act Plan
Study* Do
Study Results Execute Plans
of Actions Taken
* Shewhart used ‘Check’, while Deming preferred ‘Study’

W. Edwards Deming
• Deming popularised the Shewhart cycle
• Came to fame after working in Japan to help the
Japanese improve the quality of their
manufactured products
• Promoted the concept:
– Quality is a management issue: common causes
often beyond the ability of the worker to fix and so
require management action

Joseph Juran
• Juran defined quality from a customer’s
viewpoint as ‘fitness for use’ (five attributes: quality of
design, quality of conformance, availability, safety and field use)
• Juran’s message was that quality must be

planned
• The ‘Juran Trilogy’
– Quality planning
– Quality improvement
– Quality control

Philip Crosby
Cost of Quality (COQ) =
Price of Conformance (POC)
+ Price of Non-conformance (PONC)
4 Absolutes of Quality Management:
Quality is defined as conformance to requirements
Quality comes from prevention
Quality sets the performance standard at ‘zero defects’
Quality is measured by the cost of non-conformance
Insisted that ‘Quality is Free’

Kaoru Ishikawa
• Developed:
– Quality circles: teams within one or more
organisations meet regularly to discuss how to
improve a work process. They devise and try out
corrective actions, and report back. Meetings are held
until the team decides to disband
– ‘Cause and effect’ diagrams known as Ishikawa
diagrams or fishbone diagrams

An Ishikawa diagram or fishbone diagram
Inexperienced
Too many bugs
project team
Lack of inspections
Insufficient prior
project experience
Too many
Poor training last minute changes
Work rushed
Software not
delivered on-time
New hardware Too much rework Requirements
arrived late specification
too imprecise
Poor documentation
Lack of knowledge Unrealistic

of Evaluation Criteria deadlines
New technology Too much work Other?

Continuous improvement
• Continuously striving to produce better products
and improve processes
• Key requirement is that an organisation has

stable processes so that the impact of any
change can be understood. (Often misinterpreted as
that an organisation has to have processes!)

Six Sigma
• Holistic approach to quality. An organisation sets
high six sigma goals and uses continuous
process improvement
• Six sigma goal is no more than 3.4 defects per
million opportunities (think back to control charts)
• Adopted by Motorola and General Electric
Company (GEC)
• Builds on the work of the quality gurus such as
Deming, Juran and Crosby
• Originally a five step DMAIC improvement
process. It has now become eight step

Six Sigma improvement process
• Identify the project
• Define the project
• Measure current process performance
• Analyse/probe the problem
• Develop the improved process
• Implement the changes
• Control - measure and hold the gains
• Communicate - exploit the achievement in other
areas

Industry quality standards
ISO 9000:2000 Standards for quality management
with respect to improved customer satisfaction
and continuous improvement. Focuses on eight
principles:
– Customer focus See http://www.iso.org
– Leadership
– Involvement of people
– Process approach
– System approach to management
– Continual improvement
– Factual approach to decision making
– Mutually beneficial supplier relationships

Industry quality standards
TickIT
• TickIT provides a framework for organisations to
get certification under the ISO 9001:2000
framework
• Develops quality management system
certification procedures:
– Publishes guidance material for interpreting the
requirements of ISO 9001
– Advises on training, selecting and registering auditors
with IT experience and competence
– Introduces rules for the accreditation of certification
bodies in the software sector
(see http://www.tickit.org)

Maturity models
• Provide frameworks for organisations to assess
their overall capability
• Aim to help organisations understand what they
need to do to achieve process improvement or
enhance organisational capability

Capability Maturity Model Integration (CMMI)
• Developed by the Software Engineering Institute

(SEI) at Carnegie Mellon university. See
http://www.sei.cmu.edu
• Originally CMM but integrated other models to
become CMMI
• Two instantiations:
– Staged CMMI: assesses a whole organisation’s
process capability at one of five maturity levels
– Continuous CMMI: assesses different process areas
across an organisation individually, so a set of
maturity levels results

The CMMI staged diagram:
the maturity levels Level 5
Optimising
Level 4
Quantitatively
Managed
Level 3
Defined
Level 2
Managed
Level 1
Initial

CMMI
• Maturity Level 1: Initial: processes are ad hoc and

chaotic
• Maturity Level 2: Managed: processes are planned,
performed, measured and controlled
• Maturity Level 3: Defined: Processes are
qualitatively predictable
• Maturity Level 4: Quantitatively Managed:
Processes are understood in statistical terms and
special causes are addressed. Processes are
quantitatively predictable
• Maturity Level 5: Optimising: Focus on improving
process performance by removing common causes

Project management maturity models
• Aim to improve and standardise project

management processes
• The Project Management Institute (PMI)
produced an Organizational Project
Management Maturity Model (OPM3).
– This builds on the project management processes
described in Lecture 1 (initiating processes, planning
processes, executing processes, monitoring and
controlling processes, and closing processes)
– Extends into programme and portfolio management
(think back to Lecture 2)

Summary
• Discussed:
– Current ideas on project quality management
– Key people who have shaped quality management
• Seen that Quality:
– Must be designed into a product
– Not just about errors and their elimination: it is also
about prevention
– Is a dynamic concept
– Is concerned with the usefulness and acceptability of
a product to its users and the project clients

END

CSIT 310
Design Project
Session 9 – Project Risk Management

2016/2017 – 2017/2018
Lecture 2
Project Risk Management
2016/2017 – 2017/2018
Learning outcomes
To be able to:
– Define risk
– Define risk management
– Identify and evaluate risks
– Utilise checklists and other generic lists to
determine project risks
– Categorise and prioritise action lists for risks
– Discuss strategies for dealing with project risks

Session structure
The structure of this session is as follows:
• Attitudes towards risk are considered and a definition
of risk is given
• Risk management is defined and a risk management
process is discussed
• The benefits of evolutionary systems development to
risk management are considered
• An approach to dealing with deadline pressure is
suggested
• A generic checklist of risks for student projects is
given

Attitudes towards risk
Popular perspective of risk:
• Is it safe to use mobile phones because of radiation?
• Do mobile phones masts affect the growth of
children? Is their radiation level acceptable?
• Should we consume genetically modified food?
What do we do about genetic mutations?
• Is our drinking water safe? From aluminium?
From microbes?
• Is it safe to eat fish from a contaminated sea?
• Is it safe to fly due to deep-vein thrombosis?
• Is climate change threatening our coastline?
• Will a large asteroid strike our planet?
• Was the most recent train accident predictable?
Could it have been stopped?

Distinguish between objective and subjective risks:
• Objective risk represents what actually
exists: the true magnitude of a given risk
• Subjective risk is what the analyst,
manager or the observer believes to be
the risk
Usually we are dealing with subjective risks

Tolerance towards risk varies. Individuals and
organisations have different attitudes. Preferences
for risk:
• Risk-averse
• Risk-neutral
• Risk-seeking

Definitions of risk
• Basic dictionary definition:

“chance of bad consequences”
(Pocket Oxford Dictionary, Revised Fourth Edition with corrections, 1961)
• PMI’s PMBOK Guide:

“An uncertain event or condition that, if it occurs, has a
positive or negative effect on a project’s objectives”
(PMBOK Guide 2004)
• Kerzner:
“Risk is a measure of the probability and consequences
of not achieving a defined project goal” (Kerzner 2003)

Definition of risk
• Definitions convey that for a given event, there are
two main components of risk:
– Probability or likelihood of the event occurring
– Impact if the event occurs (what is at stake?)
As either probability or impact increases, so does the

risk…

Risk is a function of probability and impact
High
High
Risk
Probability
Moderate Risk
Low
Risk
High
Size of Impact
Hazards and safeguards
• Kerzner makes the point that risk is also a matter of
knowing about the source of a risk (a hazard) and
taking action to avoid it (a safeguard). For example,
avoiding a known pothole in a road. (Kerzner 2003)

How we refer to risk
These varying definitions explain why we refer to risk in
different ways:
• As a probability: for example, ‘the risk that this will
happen is 10%’
• As an impact: for example, ‘the risk is that a car
accident will happen’ or ‘we shall lose 100
monetary units’
• By its source: for example, ‘lack of user
involvement’ or ‘lack of adequate testing’

Costs and benefits associated with risk
Looking at risks in terms of impact: costs and benefits

• Costs:
• (Unexpected) losses
• The cost of uncertainty itself:
– Strain: both physical and mental (for example, stress and panic)
– Less than optimal performance including improper use of resources,
timing problems, oversupply, undersupply, and degraded decision
quality
• Benefits:
• Performance: the only way to achieve anything is by taking risks
• Potential for opening up creative chances

Approach to risk management
• Risk management implies the ability to identify,
quantify and control risks accurately
• Project managers must be proactive towards risk
management
• Recognise that total elimination of risk is impossible
(and may even be undesirable)

Definition of project risk management
• The Project Management Institute (PMI) A Guide to the

Project Management Body of Knowledge (PMBOK) defines
project risk management as:
“The processes concerned with conducting risk
management planning, identification, analysis,
responses, and monitoring and control on a project.
The objectives of Project Risk Management are to
increase the probability and impact of positive events
and decrease the probability and impact of events
adverse to project objectives” (PMBOK Guide 2004)
• In outline, risk management involves:
– Continuously assessing risks
– Determining what risks need dealing with
– Implementing strategies to deal with those risks

Project risk management
• Must be an ongoing activity throughout the life of a
project
• Must be fully integrated into the work of the project
team
• Needs a process…

The risk management process
Risk
Management
Iteration
Risk Organisational Risk Risk Risk Risk Risk Risk Reflection &
Policy Context Identification Assessment Evaluation Planning Control Monitoring Communication
Description of Lessons
Quantified
Project Organisational Prioritised Risk Plans & Learnt
Potential Risks: Risk
Risk Objectives & Risk Contingency Feedback & Process
Risks Probability Assessments
Policy Background & Action List Plans Improvement
& Impact
Environment Suggestions

Risk policy
• Risk policy involves deciding how the project should

approach risk:
• What is the organisational risk policy? Are there any
standard policies and templates? Is there any previous risk
data?
• What is the risk tolerance of the sponsors of this project?
• How ambitious is this project? What is at stake with this
project? What level of risk should be taken on?
• What methods for risk management are to be adopted?
• Who is to take main responsibility for risk management?
• What level of contingency planning is needed? What
contingency resources are required?
• What specific risk policy should this project adopt?

Organisational context
• Organisational context: the organisational
context in which the project exists, which
includes investigating such things as:
– The organisation’s mission statement, the organisational
objectives and strategic plans
– Any specific strategies: For example, IS plans and
security plans
– The historical background to the project being initiated
– Other current projects

Risk identification
Risk identification involves identifying, categorising and
characterising risks.
What are the risks? What kinds of risks are they?
Useful means of identifying risks include:
• Using checklists (identifying generic risks)
• Using critical success/failure lists (highlighting generic problems or
issues)
• Examining task decomposition (your WBS can reveal specific
problems)
• Investigating decisions, rationales and assumptions already made
on the project
• Detailed reading of activity plans (with a particular emphasis on the
critical path and events close to being on the critical path, as well
as making sure that events off the path are not likely to be exposed
to major problems)
• Examining project specifications to uncover other problems
• Interviewing people with recent experience on similar projects
• Asking
All material presented in a
thispanel ofonexperts
course is based the (Delphi technique)
Checklist of generic risks
Generic risks include:
• Personnel shortfalls: for example, loss of key staff;
difficulty in recruiting specialists
• Unrealistic budgets and schedules: for example,
aggressive targeting with little regard to reality
• Continuing stream of requirements changes: for
example, users who were denied adequate
consultation at the outset of the project
• Use of unproven technologies: for example,
component-based development in an organisation
only familiar with procedural languages, such as C

Critical success factor lists
Critical success factors include:
• User involvement
• Clear statement of requirements
• Proper planning
• Realistic expectations
• Smaller project milestones
• Competent staff
• Ownership
• Clear vision and objectives
• Hard working, focused staff
• Technical feasibility

Failure factor lists
Failure factors include:
• Changes to requirements
• Unrealistic deadlines
• Inaccurate estimation
• Ignored risks
• Weak design
• Lack of motivation
• Poor progress tracking due to lack of visibility
• Inexperienced management
• Insufficient or late testing
• Failure of suppliers
• New technology

Risk types
• Risks can be categorised into risk types, such as:
• Personnel
• Organisational
• Environment
• Process
• Technology
• Tools and equipment
• Costings, measurement and schedules

Risk assessment
• Risk assessment attempts to characterise,
qualify and quantify these threats (and
opportunities) to enable effective decision-making
• One approach towards prioritising risks is to
estimate ‘risk exposure’
Risk exposure = Probability x Impact

(of a risk) (Loss as a result of the
risk materialising)
• The risk exposure information can be captured as a

decision tree

A decision tree showing risk exposure
20%?
Project Late 3000mu
No Penalty
Recruit
only
80%? 3000mu
50% Project Late + Penalty
Penalty
Technical
Specialist
3000mu +
Leaves
Subcontractor
Recruit &
100% Costs
Sub-contract
Technical
Specialist 100% 0mu
Stays
50%

Problems with risk exposure
• How do you equate two risks with the same risk
exposure when one has a low probability and huge
impact and the other has a higher probability and a
lower impact? Where are your resources better
spent?
• You can plot percentage probability against impact to
identify the highest risks

As shown in the earlier slide:
Risk is a function of probability and impact
High
High
Risk
Probability
Moderate Risk
Low
Risk
High
Size of Impact

Risk evaluation
• Risk evaluation looks at potential options for

overcoming the effects of risk culminating in the
selection of the most suitable strategies
• Four basic risk strategies are:
– Risk avoidance
– Risk acceptance
– Risk transference
– Risk reduction
• Risk reduction leverage (RRL)

RRL = Reduction / Cost
where Reduction is RE (before the solution) - RE (after)
Risk planning
• Risk planning plans the implementation of the strategies
to deal with the risk prior to the risks adversely affecting
the project’s progress
• Need to ensure the planned tactics do not clash or duplicate
• Risks you are to deal with upfront need resources allocating
• Risks you are to deal with when they happen need

contingency funding

Risk control, risk monitoring,
and reflection and communication
• Risk control is the actual execution of the selected risk
management strategies
• Risk monitoring tracks the project and the success of the

selected strategies and specific tactics in dealing with the
effects of identified risks, while also monitoring for new or
revised risks (threats and opportunities)
• Reflection and communication attempt to learn the

lessons from the present to improve organisational (and
personal) ability to address risks in the future

Evolutionary systems development and risk
Evolutionary approaches can help with risk:

• Small evolutionary steps mean there is only a small amount of the total
time and total effort allocated - typically 2% to 5%
• Measurement of progress occurs at the end of each evolutionary step, so
the project gets an early chance of feedback and can take any necessary
corrective actions
• The project gets early feedback from the users so it knows if the outcomes
are off-track and are not what the users actually require
• The steps are prioritised so that the users get the high-value steps
delivered earliest
• The project team also has the ability to try out high-risk steps early and
find out just how much of a problem they are
• Smaller steps are easier to control, so there is less risk involved
(Gilb 2005)

Dealing with deadline pressure
Tom Gilb’s ‘ten suggestions’ are as follows:

• Re-think the deadline given - is it for real?
• Re-think the solution - is it compatible with the deadline?
• What is the client’s point of view on this problem? Does that help you
understand their real needs?
• Don’t accept ‘expert’ opinions blindly. Insist on evidence that something
will work – has it worked before now?
• Determine which requirements must be delivered by the deadline. Some
requirements will be crucial, but your client probably doesn’t need
everything by then
• Don’t cave in and accept impossible deadlines, even as a last resort
• Change the solution to meet the deadline
• Make maximum use of existing systems and known technology
• Break the project into earlier and smaller deliverables. Remember to think
about the results that you want to deliver, not the technology
Don’t
All •material forget
presented to istake
in this course credit
based on the for the success
Summary
• This lecture has discussed:

– Definitions of risk and risk management
– The risk management process
• Too few projects manage risk in a systematic way.
Often approaches tend to be ad hoc, undocumented
and incomplete
• Risk management is increasingly becoming part of
mainstream software engineering and project
management. Increasingly the use of structured and
controlled risk management is being demanded

END

CSIT 310
Design Project
Session 10 – Project Review and Reflection

2016/2017 – 2017/2018
Learning outcomes
At the end of this lecture you should be able to:
– Understand how to carry out an end-of-project evaluation
– Reflect on project events, problems and deliverables
– Adopt a professional attitude to continuous improvement
and personal development in project work

Project management processes
• Initiating processes
• Planning processes
• Executing processes
• Monitoring and controlling processes
• Closing processes
(PMBOK Guide 2004)

Closing processes
This session is concerned with the Closing
processes activities. We define ‘Closing’ as
follows:
Formalising the acceptance of the

project or phase, and ensuring all
relevant documentation is put in place
Note the use of the phrase, ‘or phase’, it indicates

that closing activities should occur at the end of
each phase throughout the life of a project

Closing processes’ activities
This session is going to focus on two aspects:
– Post-delivery reviews (PDRs)
– End-of-project reports

Post-delivery review (PDR)
• Sometimes known as a post-completion review (PCR)
or post-implementation review (PIR)
• Important to learn from feedback of experience:
– For the individual
– For the organisation
• Reinforces good behaviour and identifies what does
not work
• Not an occasion for disciplining or punishment
• Aim is to facilitate learning and improvement
Sources to support a PDR
The actual project documentation:
– Aim and objectives of the project
– The WBS
– The Gantt chart
– The critical path
– The risk management documents
– The reports from earlier project review meetings
Access to members of the original project team as they
can provide the rationale behind the decisions made

Scope of a PDR
The specific aspects for a PDR to consider include:
– The success of the product produced (delivered value/actual benefit)
– How the project is delivered with regard to the project triangle factors
(financial budget, schedule and scope) and the specified quality
objectives
– The project process including the quality of the project documentation
and the project plans
– The team working
As well as looking at the team working, an individual performance review

should be carried out for each member of the project team

Who carries out a PDR?
• The project manager carries out the project PDR with
the rest of the project team
• An independent PDR or project audit can also be
carried out by people external to the project
• Individual performance reviews are carried out by
the project manager holding separate reviews with
each individual

Checklists
Checklists are used. For example:
• The project/product checklist
• The project triangle checklist
• The process checklist
• The team checklist
• Dealing with problems checklist
• The project reflection checklist

The project/product checklist
• Was the main project aim achieved?

– Was it achieved within the schedule/financial budget projections?
• Were the project objectives clearly defined?

• Were all aspects of the work completed?
– Are there any aspects that remain undone? (Note in your student
project reports, this would give you scope for discussion in the last
part of your report when you talk about problems and future plans.)
• Did the project give the client what was promised?

• Are the users happy with the result?
– Is it what they needed?
– Were their needs correctly identified?
– Did their needs change during the course of the project?
• Were all stakeholders identified from the outset?

The project triangle checklist
• How accurate was the financial budget?
– Was the planned budget exceeded?
– If so, why?
– What problems caused the escalation?
– Could they have been predicted?
– Could they have been avoided?
• How accurate was the schedule?

– Was the planned schedule exceeded?
– If so, why?
– What problems caused the escalation?
– Could they have been predicted?
– Could they have been avoided?
– Was it just one problem that delayed all other activities or were all activities
mis-estimated?

The project triangle checklist
Continued …
• Was the original scope achieved?
– Were there any changes to scope during the duration of the project?
– Why were they approved (or why were they needed)?
– Did they lead to any escalation in either budget or schedule?
• Was the overall quality acceptable?

– Were the test plans adequate?
– Did they pick up all the errors that you know about?

The process checklist
• What process was used to manage the project?
• What parts of the process worked well?
• What parts of the process would be done differently if you
had a second chance?
• Were milestones observed?
– Why not?
• What were the reasons for misapplying them?

The team checklist
• Was the team effective?
• Did the team work together and support each other?
• Would you define the entire project as a success?
Why/why not?
• Was the project organised effectively?

Dealing with problems checklist
If you have identified any major events that have taken
place, ask yourself:
• Was this event positive or negative in terms of impact on the
project?
• Was it predictable?
• Was it avoidable?
• When was it identified?
• Were the actions effective from that stage on?
• Was the communication chain effective?

The project reflection checklist
• What where the main strengths of the project?

• What were the major weaknesses?
• What changes would you recommend for the next project?
• Did you learn anything from this project?
• Do you think the project was effectively managed?
• Was the overall communication process effective?
– Where did it break down? Did this happen often?
• Did any of the methods work particularly well?
• What would you change in the management of the project?
• Describe one thing that you could have done personally to improve the
outcome of the project

What do you do with the lessons learned?
• Lessons need to be shared

• Revisit working practices
• Use lessons to facilitate training
• Maintain a repository of key lessons
• Ensure project managers access the resource prior
to embarking on a new project

End-of-project reports
Purposes of end-of-project reports:
• Informing stakeholders that project work has finished
• Describing the delivered project/product
• Setting out the achievements of the project
• Documenting all the artefacts/products produced by the
project
• Handing over the product
• Requesting product signoff
• Releasing resources
• Stating additional work that is still needed
• Thanking people for their help and their effort

Contents of end-of-project reports
Marchewka (2006) suggests as a minimum:

• Project summary
– project description
– project measurable organisational value
– scope, schedule, budget, and quality objectives
• Comparison of planned versus actual

– original scope and history of any approved changes
– original scheduled deadline versus actual completion date
– original budget versus actual cost of completing the project
– test plans and test results

Contents of end-of-project reports
Continued …
• Outstanding issues
– itemised list and expected completion
– any on-going support required and duration
• Project documentation list

– systems documentation
– user manuals
– training materials
– maintenance documentation

Caveats
Note the last two slides on the contents of end-of-
project reports:
• Are more about project progress and handover. They
do not include PDR content (Marchewka discusses
project post mortem reviews separately)
• Are more industrial in their approach. They are

insufficient to satisfy the academic requirements for
a student project report

Summary
This session has covered:
– Post-delivery reviews (PDRs)
– End-of-project reports
It should have given you some ideas and help about

how to reflect on project experiences in a
professional manner

END


CSIT 310 Design Project

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CSIT 310 Design Project

Uploaded by

Copyright:

Available Formats

CSIT 310

Session 0 – Introduction to Design Project

Lecturer: Dr. Ferdinand Katsriku, CSD

All material presented in this course is based on the

All material presented in this course is based on the book by

All material presented in this course is based on the book by

All material presented in this course is based on the book by

All material presented in this course is based on the book by

All material presented in this course is based on the book by

All material presented in this course is based on the book by

All material presented in this course is based on the book by

All material presented in this course is based on the book by

All material presented in this course is based on the book by

All material presented in this course is based on the book by

All material presented in this course is based on the

All material presented in this course is based on the

All material presented in this course is based on the

AIMS AND OBJECTIVES

All material presented in this course is based on the

All material presented in this course is based on the

All material presented in this course is based on the

All material presented in this course is based on the

All material presented in this course is based on the

All material presented in this course is based on the

All material presented in this course is based on the

All material presented in this course is based on the

All material presented in this course is based on the

All material presented in this course is based on the

All material presented in this course is based on the

All material presented in this course is based on the

All material presented in this course is based on the

All material presented in this course is based on the

All material presented in this course is based on the

All material presented in this course is based on the

All material presented in this course is based on the

Goals and Objectives

All material presented in this course is based on the

All material presented in this course is based on the

All material presented in this course is based on the

All material presented in this course is based on the

All material presented in this course is based on the

All material presented in this course is based on the

All material presented in this course is based on the

All material presented in this course is based on the

All material presented in this course is based on the

Session 1 – PROJECT AND PROJECT MANAGEMENT

Lecturer: Dr. Ferdinand Katsriku, CSD

Introduction to projects and

All material presented in this course is based on the

“A temporary endeavor undertaken to create a unique

All material presented in this course is based on the

All material presented in this course is based on the

All material presented in this course is based on the

All material presented in this course is based on the

All material presented in this course is based on the

“Project management is the process by which

All material presented in this course is based on the

All material presented in this course is based on the book by

All material presented in this course is based on the

All material presented in this course is based on the

All material presented in this course is based on the

Technical Failure Human Failure Process Failure

Project management lifecycle Manage the