CSC 416 - 421 Notes

CSC 416/421
Software Project Management

Course Outline - I
 The course will focus on the integration of business and
technical considerations in the design, implementation and
management of Information Systems
 Topics
 Information Systems overview
 Project Management – key concepts
 Software Project Management Overview
 Project Lifecycle and Software Development Lifecycle
 Project Roles and Responsibilities
 Project Management Tools and Methodologies
Course Outline - II
 Managing Software Projects
Team and Stakeholder Management
Cost and Size Estimation
Planning and Scheduling
Risk Management
Configuration and Quality Management
Performance Measurement Techniques
 Case Studies
Learning Outcomes
 By the end of this course students should:
 Understand the basic concepts and underlying
principles of Project Management.
 Apply project management principles and discipline
to the design, development, integration and
management of Software Systems
 Have a keen appreciation of Project Management
Roles and Responsibilities, Stakeholder management,
Risks and Risk Management especially as they apply to
the Software Industry in Nigeria.
Recommended Textbooks and References
 Information Technology Project Management by Kathy Schwalbe
[8th Edition, Cengage Learning, 2015]
 Software Engineering by Ian Sommerville [10th Edition, 2015]
 Software Project Management by Bob Hughes and Mike Cotterell

[5th Edition, McGraw-Hill Companies, 2011, ISBN 007 709505 7]
 Guide to Project Management Body of Knowledge

[PMBOK GuideAgile 6th Edition, PMI, 2017, ISBN 978-1-62825-3282-5]
INFORMATION SYSTEMS OVERVIEW
 An Information System is a set of tools, processes and
people working together to collect, retrieve, process,
store and distribute information for the purpose of
facilitating planning, control, analysis and decision
making in an organization
 In modern times, an Information System uses
Information Technology to capture, transmit, store,
retrieve, manipulate or display information used in one
or more business processes.
 Specialised skills are needed to design and implement
Information Systems. One of such skills is Software
Project Management
INFORMATION SYSTEM vs INFORMATION TECHNOLOGY
Project Management – Key Concepts - I
 Project – a temporary endeavour undertaken to create a unique product,

service, or result (PMI)
 A project - a unique set of activities meant to produce a defined

outcome within an established time frame using specific allocation of
resources (HBS).
This definition includes a subtle introduction to the famous
“triple constraints” - time, scope, cost.
 Project Management – the application of knowledge, skills, tools and

techniques to project activities to meet project requirements (PMI)
Project Management – Key Concepts - II
 A Project is a temporary endeavour undertaken to create a unique
product, service, or result
 Projects are undertaken to fulfil certain objectives by producing
deliverables.
 An objective may be:
 an outcome towards which work will be directed
a strategic position to be attained
a purpose to be achieved
a result to be obtained
a product to be produced
a service to be performed.
Project Management – Key Concepts - III
 Fulfilment of project objectives can produce one or more of the following
deliverables:
 A unique product can either be a component of another item, an
enhancement or correction to an item
 A unique service or a capability to perform a service (e.g. a business
function that supports production or distribution)
 A unique result, such as an outcome or document (e.g. a research project
that develops knowledge that can be used to determine whether a trend
exists or whether a new process will benefit society)
 A unique combination of one or more products, services or results (e.g. a
software application, its associated documentation, and help desk services)
 Projects drive change, taking an organization from a current state
to a desired one, with a view of enhancing business value.
Why create a Project ?
 These factors influence an organization’s ongoing operations and business strategies.

 Projects provide the means to successfully make the changes necessary to address these factors
 Business Leaders respond by sponsoring projects which help keep the business viable.
Factors that lead to the creation of Projects
Factors that lead to the creation of Projects
Project Management in an Organization
Project, Program, Portfolio - I
Project, Program, Portfolio - II
Project, Program, Portfolio - III
Project, Program, Portfolio - IV
Roles & Responsibilities of a Project Manager
 A Project Manager is:
 Responsible for accomplishing project objectives
 Represents the Client (Business) and is responsible for
meeting the Client’s requirements
 Key responsibilities include:
 Defining and communicating project objectives
 Acquiring project resources such as people,
data/information, agreements/contracts, technology
etc. needed to accomplish project objectives
 Managing project management constraints – scope,
schedule, cost, quality, resources, risks
Knowledge & Competencies of a Project Manager
 Knowledge of Project Management, the business
environment and technical aspects of the project
 Interpersonal skills to effectively manage the project team
and stakeholders
 Effective communication, motivation, coaching, influencing
 Leadership, Facilitation, Coordination and Decision making
 Problem solving, negotiation, conflict management
 Political and Cultural awareness
 The Project Manager is considered successful when project
objectives have been met and Stakeholders are satisfied
Project Manager and the Organization - I
 Projects operate within certain Organizational Structures
 (a) Functional, (b) Matrix, (c) Projectized
Project Manager and the Organization - II
Project Manager and the Organization - III
Project Manager and the Organization - IV
What is in a name ?
 The Project Manager is the person assigned by the organization
to achieve the project objectives.
A software project covers much more than
writing software code. It is possible for an off-
the-shelf software package to be implemented as
a project.
A software projects usually involves: feasibility
study, planning and project execution.
A more detailed lifecycle involves: requirements
analysis, specification, design, coding, testing
and validation, implementation,
maintenance/support
 3 key characteristics that differentiate Software Projects from other
projects
 Invisibility- When a physical structure such as a bridge or road is
being constructed, the progress is visible to all, but with software
projects, this is not so
 Complexity – Per unit of cost spent, software products are far more
complex than physical structure projects
 Flexibility– The ease with which a software product can be
changed is one of its strengths. This means that software systems
are more likely to be subject to a high degree of change. For
integrated and interfaced systems, changes to software should not
necessarily occasion changes to other components
Categories of software projects
 A software project can deliver:
 Application software e.g. Payroll, Examination Processing,
Productivity tools such as Email, Microsoft suite
 System software e.g. operating systems, device drivers, desktop
environments
 Information systems - include the application software, data,
processes, decision support and reporting systems
 Embedded systems – software to drive computer hardware and other
electromagnetic devices, often in a real-time environment. e.g. dcs
for oil and gas production, Airplane navigation system
 Development tools e.g. Python, Java, Assembler, Compilers
Project Management Phases/Lifecycle
PDCA is the basis for most of the modern day Project Management Lifecycle
Project Management Lifecycle (PMI)
 5-Phase (PMI)
• 4-Phase
• Definition
• Planning
• Execution
• Delivery (& Closure)
• 3-phase
• Inception
• Initiation
• Execution (& Closure)
Generic Project Management Lifecycle
11/16/2021 31
Project Plan and Progressive Elaboration
Progressive Elaboration
As the project progresses, the project
plan is fleshed out in greater detail
The final and complete Project Plan
results from successive iterations of the
initial project plan
11/16/2021 32
Project Phases Timeline (PMI)
 Phases overlap and could be iterative (progressive elaboration)

Project Management Boundaries
Project Stakeholders
Stakeholders may be Internal or External
Project Roles and Responsibilities - I
Project Roles and Responsibilities - II
Project Roles and Responsibilities - III
What is a PMO ?
Examples of Project Roles and Responsibilities
http://its.ucsc.edu/project-management/docs/brown-bag-docs/project-roles-and-resp-for-
presentation.pdf
http://www2.mmu.ac.uk/media/mmuacuk/content/documents/bit/Project-Roles-toolkit-v2.pdf
Project Stakeholder Management - I
 Stakeholder Management steps:
 Identify the people, groups or organizations that could impact or be
impacted by the project.
 Recognize those who could impact the project positively or
negatively (allies and adversaries)
 Some stakeholders have a limited ability to influence the project
work or outcomes, while others have significant influence that
could either assist or jeopardise the project
 Analyse each stakeholder’s expectations and the impact of such
expectations on the project
 Develop appropriate strategies to effectively engage all stakeholders in
order to gain maximum support for project decisions and execution.
 This document is sometimes called a Stakeholder Management Plan
Project Stakeholder Management - II
 Stakeholder Analysis
 Identify each potential stakeholder (Stakeholder Register)
 Assess the level of interest each Stakeholder has in the project.
 Recognize how much decision-making power each Stakeholder wields
 Create a power/influence grid and develop suitable communication strategy
Project Stakeholder Management - III
 There must be a clear and targeted communication plan to different
Stakeholders
 Use appropriate tools to communicate timely and practical information
to Stakeholders in order to:
 create awareness and
 build support for the project
 Communication Methods
 Interactive. e.g. face-to-face meetings, conference calls, group chats etc.
 Push. e.g. Email, Newsletters, Bulk SMS
 Pull. e.g. Project Website, Social Media account
Project Stakeholder Management - IV
Goal : Use appropriate tools to communicate timely and practical information to Stakeholders in order to create awareness and build support for the project
 Sample Project Communication Tools
Target
Tool Audience Mode Material Purpose Frequency
Stewardship package,
Issue write-up etc.
Stewardship Sponsor and Include Communicate high-level
Reports - Steering Red/Yellow/Green score status, progress and
Summary Committee Face-to-face meetings card and current Issues issues Monthly/Quarterly
Detailed Report by major
High-level areas impacted. Include Communicate detailed
Stewardship Stateholders Face-to-face meetings or Red/Yellow/Green score status, progress and
Reports - Detailed (Champions) Email card and current Issues issues Monthly/Quarterly
Detailed Project Status
Report. Include Communicate detailed
Stewardship Face-to-face Red/Yellow/Green score status, progress and
Report - Internal Project Team meeting/Project Portal card and current Issues issues, Collaboration Weekly/Monthly
1- 2 pages on single
Customer sheet.
Newsletter - Hints Service/End Common tips on Logon,
& Tips Users Email Navigation, Reports etc Quick Reference Guides Quarterly
Customer Awareness; General
Newsletter/Project Service/End Email, Bulk SMS or General interest news - Information about the
Website Users Social Media feed what's going on project Quarterly
Graphic design (could be Create/adopt a logo to be
sourced internally via used on all key Awareness and Visual
Project Logo General competition) documentation reminder One time
T-shirts, Face caps,

Brand Physical Distribution of Mouse pads, Cup holders Commemorative - major At Project Close or
Merchandise General items etc with Project Logo milestones major milestones
Project Stakeholder Management - V
 Every project should have Stakeholder Satisfaction as an objective
 The Project Manager should continuously engage and communicate with
stakeholders in order to understand their needs and expectations, address
issues as they arise, and manage conflicting interests.
 The ultimate goal is to transform non-supportive stakeholders into allies
Stakeholder UNAWARE RESISTANT NEUTRAL SUPPORTIVE CHAMPIONS

Stakeholder 1 C D
Stakeholder 2 C D
Stakeholder 3 C D
Stakeholder 4 C D
C = Current State
D = minimum Desired state
Project Stakeholder Management - VI
 Stakeholder Engagement is easier when all Stakeholders understand
their Responsibilities towards the project
Project Stakeholder Management - VII
Responsibility Assignment Matrix using a RACI Chart
Steering Project Subject Matter Training Suppliers /

Activity Sponsor Committee Manager Business Lead Experts IT Lead IT Experts PMO Consultant Contractors
Provide Resources A R C I C C C S I I
Own Scope and Priorities A R C C C S S S I I
Maintain and Control Scope I A R S C S S S I I
Define Roles & Responsibilities for Processes I A C R C S S I S I
Communicate Priorities I A R I C S C I I I
Resolve Business Issues I A C R C S S I I S
Communicate Project Status I I A R C R C S S I
Deliver Project Objectives S C A R C C S I S S
Plan and coordinate Testing cycles I A C R C S S I I I
Steward Project Costs & Schedule I I A S R S S R I I
Develop Training Material I I C A S I I I R I
Deliver Training I I A S S S S I R I
Manage overall Project activities I S A S S S S R I I
For each activity, there must be one Accountable person and at least one Responsible person
Project Scope Management
Project Management – Project Constraints
Traditional Triple Constraints
Project Management – Project Constraints (PMI)
The PMBOK® GuideAgile (6th Edition) lists the following as Project

Constraints:
• Scope
• Quality
• Schedule
• Budget
• Resources
• Risk
Some practitioners add “Customer Satisfaction”
PDCA is the basis for most of the modern day Project Management Lifecycle
Project Management Lifecycle (PMI)
 5-Phase (PMI)
• 4-Phase
• Definition
• Planning
• Execution
• Delivery (& Closure)
• 3-phase
• Inception
• Initiation
• Execution (& Closure)
Project Scope
Developing a Project Scope is a “Planning”, “Definition”, or “Inception” Activity

Projects and Products
Project Scope and Statement
• Project Scope is the work that must be performed to
deliver a product, service or result with the specified
features and functions
Defining the Project Scope: Project Charter - I
 A Project Charter is a document that states that a project
exists and provides the Project Manager with written
authority to begin work.
 The Project Charter is used by the Project Manager to:
 Communicate his/her authority to project stakeholders
 Describe why the project is needed (Project Objectives)
and benefits to the organization on completion
 State the project duration, cost, and types and resources
required, i.e. summarise the Project Scope
Defining the Project Scope: Project Charter - II
Defining the Project Scope: Project Charter - III
SOW = Statement of Work

Project Risk Management
Project Risk Management - I
 Basic definition of Risk
 The potential of gaining or losing something of value which may
result from a given action or inaction (Wikipedia)
 The probability or threat of damage, injury, liability, loss or any
other negative occurrence that is caused by internal or external
vulnerabilities (Business Dictionary)
 Exposure to the possibility of loss, injury, or other adverse or
unwelcome circumstances (English Oxford Dictionary)
 In Project Management, Risk is an uncertain event or
condition that, if it occurs, has an effect on at least
one project objective.
Project Risk Management - II
 Project Risk management is the process of identifying risks and
drawing up plans to mitigate/minimise their effect on a project.
 Risk management is particularly important in Software Project
Management because of the inherent uncertainties in software
development.
 These uncertainties could be due to:
 loosely defined requirements
 changes in customer needs leading to changes in requirements
 difficulties in estimating the time and resources required for
software development
 differences in individual skills levels within the project team
Project Risk Management - III
 All projects carry a certain amount of risk. Complex projects such as
Software Projects are prone to some risks.
 Not all risks can be totally eliminated or avoided
 Organizations often choose to allow certain risks in a controlled and
intentional manner, in order to create value, while balancing the risk
against the cost and reward of implementing risk mitigation procedures
 There are 2 broad classes of risks
 Inherent Risk - assume no controls are in place or all controls
have failed. This is often referred to as the Gross Risk. It is the
worst case scenario of risks.
 Residual Risk – the level of risk remaining after all controls have
been put in place. This is often referred to as the Net Risk.
Project Risk Management - IV
 A Project Manager needs to:
 anticipate risks
 understand the impact of these risks on the project and the
business
 understand what levels of risks the business is willing to support
(risk appetite)
 take steps to avoid unwanted risks or minimise their impact.
 Controls to eliminate/reduce Inherent Risks
 Processes to minimise the impact of Residual Risks
What is a Risk Register ?
 A risk register is a repository of all identified project risks, showing the
description, category, probability, impact, owner, mitigation, status etc.
 Simple example (Wikipedia) – Planning a Party
 Watch this → https://youtu.be/voR0FBnC2ZU

Project Risk Management - V
 Risk Management Process is in 4 steps:
 Risk identification - identify project, product and business risks
 Risk analysis - assess the likelihood (probability) and consequences
(impact) of these risks
 Risk planning - draw up plans to avoid or minimise the effects of the
risk
 Risk monitoring - monitor the risks throughout the project
 Above Risk Management information is usually recorded in a Risk Register
Example: Risk Impact Scaling
 Risk Probability can be similarly scaled

Risk Probability and Impact Matrix
 Need Mitigation plans for all High and most Medium Risks
Examples of Software Project Risks
Risk type Possible risks
Estimation The time required to develop the software is underestimated.

The rate of defect repair is underestimated.
The size of the software is underestimated.
Organizational The organization is restructured so that different management are responsible for the project.
Organizational financial problems force reductions in the project budget.
People It is impossible/difficult to recruit staff with the skills required.

Key staff are ill and unavailable at critical times.
Required training for staff is not available.
Requirements Changes to requirements that require major design rework are proposed.
Customers fail to understand the impact of requirements changes.
Technology The database used in the system cannot process as many transactions per second as
expected.
Reusable software components contain defects that mean they cannot be reused as planned.
Tools The code generated by software code generation tools is inefficient.

Software tools cannot work together in an integrated way.
Software Project Risks in Nigeria
 What are some of the Risks facing the software industry in Nigeria ?
Software Project Risks in Nigeria - I
 Risks facing the software industry in Nigeria
 Insufficient number of well-trained IT workers
 Inadequate knowledge and exposure of the few IT graduates
available
 High staff turn over. (Highly skilled staff are in high demand)
 High technological obsolescence / Technological limitation
 Financial constraints – access to capital
 Poor financial management on the part of the Owner/founder
 Inadequate regulation or enforcement to protect Intellectual
Property (IP)
Software Project Risks in Nigeria - II
 Risks facing the software industry in Nigeria
 Low level of user education and Management support
 Ambiguous requirement definition / specification
 Frequent change of user requirement
 Inadequate knowledge of relevant business areas
 Lack of proper organizational structure
 Poor Management (and Project Management) Skills
 Inadequate knowledge of Systems and Processes, especially IT-
related
 Underestimation of Project constraints, especially scope, cost,
and time for software development
Software Project Risks Mitigation Strategies
 Once the likelihood (probability) and impact (consequence) of identified project
risks have been assessed, a pattern begins to emerge from the prioritised list.
 The mitigation steps to be taken will depend on where the risk ends up on the grid
Project Risks Mitigation Handling Options
 Assume/Accept: Acknowledge the existence of a particular risk, and
make a deliberate decision to accept it without making any special
effort to control it. Approval of project sponsor is required.
 Avoid: Adjust program requirements or constraints to eliminate or
reduce the risk. This adjustment could be accommodated by a change in
funding, schedule, or technical requirements.
 Control/Mitigate: Implement actions to minimize the impact or
likelihood of the risk.
 Transfer: Reassign organizational accountability, responsibility, and
authority to another stakeholder willing to accept the risk.
 Watch/Monitor: Monitor the environment for changes that affect the
nature and/or the impact of the risk.
Project Risks Mitigation Handling Options
Illustration:
 If your project requires that you stand on the edge of a cliff, then there’s a risk that
you could fall.
 If it’s very windy or if the ground is slippery and uneven, then falling is more likely
Best Practices for Project Risk Handling Options
 Assume/Accept: Collaborate with the operational users to create a
collective understanding of risks and their implications.
 Risks can be characterized as impacting traditional cost, schedule, and
performance parameters.
 Risks can also be characterized in terms of impact to project objectives,
especially if it involves reduced technical performance or capability.
 Help users to understand all these impacts, and why they may choose to
"assume/accept" the risk.
 Provide the users with possible countermeasures that can be taken to minimise
the risk impact and any residual risk that may remain.
 Help the users understand the costs of “assuming/accepting” the risk in terms
of time and money.
 Users will then decide whether the “assume/accept” option is acceptable.
 Avoid: usually involves developing an alternative strategy that has a
higher probability of success but usually at a higher cost to accomplish
a project objective. Common risk avoidance techniques include:
 use proven and existing technologies rather than adopt new
techniques, even though the new techniques may show promise
of better performance or lower costs.
 choose a vendor with a proven track record over a new vendor
that is providing significant price incentives to avoid the risk of
working with a new vendor.
 For example, a project team that requires frequent, random drug
testing on team members is practicing risk avoidance by avoiding
potential damage that may be done by someone under the influence
of drugs – poor quality work, missed deadlines etc.
 Mitigate/Control: Help control risks by analysing various mitigation options.
 For example, one option is to use a commercially available capability
instead of a contractor developed one.
 Seek out potential solutions from similar risk situations of other
organizations with similar architecture.
 Risk reduction is a form of risk control/mitigation.
 It usually involves investment of additional funds to reduce the risk on a
project.
 For example, a project manager may hire an expert to review the
technical plans or the cost estimate in order to increase the confidence in
the plan and reduce the project risk.
 Assigning highly skilled project personnel (usually more expensive !) to
manage high-risk activities is another risk-reduction method.
 Some organisations reduce risk by forbidding key executives or technology
experts to ride on the same airplane. E.g. US President and Vice President
 Transfer: is a risk reduction method that shifts the risk from the project to
another party. A common risk transfer technique is Insurance.
 Purchasing insurance on certain items. The risk is transferred from the
project to the insurance company. This is usually done for areas outside the
control of the project team.
 For example: a construction project in the Caribbean may purchase hurricane
insurance that would cover the cost of a hurricane damage to the
construction site.
 Risk sharing can also be viewed as a form of risk transfer.
 It involves partnering with others to share responsibility for the risky activities.
For example: many organizations that work on international projects want to
reduce political, legal, labour, and others risks associated with international
projects by developing a joint venture with a company located in that country.
 Partnering with another company to share the risk associated with a portion of
the project is advantageous when the other company has expertise and
experience that the project team does not have.
 Watch/Monitor: Once a risk has been identified and a plan put in place
to manage it, it is tempting to ignore it, particularly if the execution of
the mitigation appears to be working well.
 Periodically revisit the basic assumptions and premises of the risk.
 Scan the environment to see whether the situation has changed in
a way that affects the nature or impact of the risk.
 The risk may have changed sufficiently so that the current
mitigation is ineffective and needs to be scrapped in favour of a
different one.
 On the other hand, the risk may have diminished in a way that
allows resources devoted to it to be redirected.
Risk Handling and Contingency Planning
 A Contingency Plan is an alternative method for accomplishing a
project goal when a risk has been identified that may jeopardise the
accomplishment of that goal.
 Contingency Plans are also referred to as “Fall-back Plan” or “Plan B”
 Contingency Plans are usually developed for high-risk items
 They include cues and triggers, including decision/checkpoint
dates, to activate the contingency/fall-back plan
 Contingency plans are usually associated with additional funds.
 Project Managers set aside funds to address unforeseen events
that cause the project costs to increase.
 A Project with a high-risk profile will typically have a large
contingency budget.
Managing Software Project Teams
Managing Software Project Teams
 Managing a Project Team is the process of creating the team, setting
expectations, tracking the performance of team members, providing
feedback, resolving issues, and managing team changes in order to
optimize project performance.
 If this process is effectively managed, the Project Manager is able to:
 assemble a great team
 influence team behaviour
 manage conflict
 resolve issues
 appraise the performance of each team member
 optimise team performance in order to meet project objectives
Steps to ensure Project Team success
The effective identification, development and integration of the project team
is a key contributor to the overall success of a project, since it is the project
team who will be responsible for delivery of the project objectives.
Below are some key steps to Team success:
 Establish the Team - Start with the Project Management team (Team
Leads). The best project teams include representative stakeholders at
all levels, from executives to those individuals at the front line. These
lower-level individuals often have the inside knowledge of existing
processes that will be a great supplement to the (often theoretical)
knowledge of technical experts.
 Facilitate Effective Communication - Accurate, useful, timely and
credible communication is crucial to maintaining a cohesive team
environment and achieving project success. All project information
should be communicated consistently throughout each stage of the
process so all team members are equally informed. The Project
Communication Plan lays out how project communication will be
handled, the target audience, purpose, content and frequency.
Steps to ensure Project Team success
 Encourage Collaboration - Groups that plan together are typically more
successful, therefore project leaders must realise the importance of
collaborative planning and goal setting. This collaborative goal setting
allows team members to achieve individual successes, while
contributing to the overall project goals. Collaboration leads to synergy.
 Accept and Manage Problems - It should be noted that simply bringing
a group of people together does not necessarily constitute a team,
especially if the goal is to have an effective working team. One of the
biggest mistakes made by project managers is not recognising this as a
fact and then expecting their project team to hit the ground running
from day one.
 Recognition and Reward - A recognition and reward scheme will help
reinforce the importance of the key project deliverables and focus the
team on the important aspects of the project. Completion of a project
and the steps along the way (milestones) should be very rewarding for
team members. Outwardly celebrating these successes can be very
motivating for the team.
Tips for effectively managing a Project Team
 Establish a balanced team
Identify project team members with both the right technical expertise as well as a
broad spectrum of communication and thinking styles.
 Ensure clarity and ‘buy in’ to the project objectives
Regardless of the seniority or experience level of the project team members, each
person needs to be totally clear and committed to achieving the project objectives.
 Ensure line (functional) management support
When selecting project team members from different departments it is critical to gain
their line managers support and commitment to the project and the time the project
member will need to allocate to project meetings, research and agreed actions.
 Establish a team code (Ground rules)
At the first project team meeting draw on the group to identify the behaviours that
will help the project team. It can be as simple as capturing ‘expectations of the
project leader’ and ‘expectations of each team member’ on a whiteboard or flipchart.
 Recognise the stages of team development *
Research shows that all teams go through different stages of development to
reach peak performance, and however skilled and experienced each team
member is, the group dynamics will vary for each new team, and with the
arrival of a new team member or project manager.
 Use a facilitator for critical meetings
Use a neutral facilitator to help get the project team started (e.g. conduct
Team orientation) or help them navigate through a critical stage such as idea
generation or decision-making.
 Use all internal and external networks
With the project team, establish early on in the project who else could help
you with your project objectives e.g. to conduct research, view best practice,
seek opinions and learn from past experiences
* To be discussed later
 Communicate with key stakeholders
At the same time as you identify who can help you, consider who are your key
influencers for this project i.e. project sponsor, project owner, key
stakeholders, and plan your communication strategy to ensure you have their
full commitment and support throughout the project
 Plan how to celebrate the project team success
Help the team visualise success at the onset of the project as the project
objectives are still being defined, clarified or conveyed. Let the team come up
with a list of “Key Success Factors”. This will increase your success rate and
make the project team members feel valued from the beginning and more likely
to respond well to future challenges that may lay ahead.
 Review the team learning on a regular basis
Timely, regular reviews scheduled into your project plan will ensure that the
project team work in the most effective manner. This will help develop the
team spirit and ultimately their commitment to the project. Identifying lessons
learnt helps not only the team performance, but also similar projects in future.
Stages of Team Development *
Personality factors that affect Team Success
Assign tasks and leadership positions, based on demonstrated personality types

Most people have more than one personality types….here are the results of different combinations
Situational Leadership - I
 Developed by Paul Hershey and Ken Blanchard, Situational Leadership is based on
the principle that there is no single "best" style of leadership, rather, effective leaders
adapt their leadership style to the performance readiness (ability/willingness or
competence/motivation) of the individual or group.
Situational Leadership - II
Managing Virtual Teams
 A Virtual team (also known as Geographically dispersed team) refers
to a group of people working together from different geographic
locations
 A virtual team can also be described as a work group which has some
core members who interact primarily through electronic means, and are
engaged in interdependent tasks.
 Certain protocols should be in place for managing as well as being
part of a Virtual team
 Cultural awareness and sensitivity, especially in communication
 Time zone considerations
 Learning to work with or provide minimal supervision
 Self-paced, yet disciplined team contribution
 Collaboration is key
Tips for Managing a Virtual Team - I
 Working in a Virtual team is one of the emerging and contemporary
workplace trends, and it needs to be properly managed for effective
results
 Get the team together physically as soon possible after formation -

This helps team members get to know each other better, personally and
professionally, and also to create a shared vision and a set of guiding
principles for how the team will work. Schedule other face-to-face
meetings semi-annually or annually, if possible.
 Clarify tasks and processes, not just goals and roles - Simplify the work
to the greatest extent possible, ideally so tasks are assigned to sub-groups
of two or three team members. Make sure there is clarity about the work
process and who does what and when.
Tips for Managing a Virtual Team - II
 Commit to a communication charter - Create a charter that
establishes norms of behaviour when participating in virtual meetings,
such as putting your phone on “mute” when not speaking (this limits
background noise and blocks out side conversations), avoiding the use of
local slangs, talking clearly and at a reasonable pace, listening attentively
and not dominating the conversation etc. The charter also should include
guidelines on which communication modes to use in which circumstances,
for example when to reply via email versus picking up the phone versus
taking the time to create and share a document.
 Leverage the best communication technologies - Developments in

collaborative technologies — ranging from shared workspaces to multi-
point video conferencing — have made it easier to manage virtual teams.
However, selecting the “best” technologies does not necessarily mean
going with the latest and greatest. Prioritise reliability and robustness
over cutting-edge features.
Tips for Managing a Virtual Team - III
 Build a team with rhythm - Be disciplined in creating and enforcing how
and when team meetings take place. For example, regular team meetings
should take place same day and time each week. Share agenda in advance,
start and finish the meeting on time. Be considerate if you have team
members in different time zones, don’t place all the time-zone burden on
the same set of people all the time (share the pain !). Encourage work-life
balance.
 Agree on a shared language. Virtual teams often also are cross-cultural

teams, and this magnifies the communication challenges — especially when
members think they are speaking the same language, but actually are not.
 Don’t forget the one-on-ones. Leader should regularly communicate with

each team member. Due to cultural differences, some members may find it
difficult to express themselves openly during team meetings
Tips for Managing a Virtual Team - IV
 Don’t underestimate the significance of small distances. Research shows
that performance is noticeably lower for teams with people located in the
same building but on different floors when compared with teams where all
members are on the same floor. The only teams that fared worse were the
intercontinental teams, with a significantly higher level of intercultural
diversity and temporal dispersion (spanning many time zones).
 Promote self-leadership across the team. Beyond social skills, managers

need to ensure that dispersed teams have broad-based leadership
capabilities that make them more self-sufficient and self-regulating.
 Foster a “global culture.” With a global mind-set, people see themselves

as part of an international network, which helps to create an environment
that is conducive to dispersed teams. Managers and team members need to
be cognisant of and embrace the international nature of their organization.
Emerging and Contemporary Workplace Trends
 Today, with improved access to ICT, internet connectivity is almost
ubiquitous. Also, the entrance of millennials into the labour market has
brought about some changes in a typical workplace:
 Typical technology-driven contemporary workplace trends include:
 open plan offices and cubicles; dynamic workspaces
 standard devices and configuration
 ergonomic workspace (including standing desks)
 BYOD (bring your own device)
 Introduction of “social media” type tools such as IM (chatting),
Audio/Video conference tools such as GoToMeeting, WebEx, Zoom, etc.
 Collaboration and workflow tools such as MS SharePoint, Googledocs,
Project Management tools, Redbooth, Asana, MS Project, etc.
Emerging and Contemporary Workplace Trends
 Others trends are more focused on individual preferences, such as:
 flexible career options – fulltime, part-time, free agency etc.
 less formal dress code
 flexible office hours and “work from home”
 work-life balance is prioritised
 emphasis on team work
 speed is of essence
 less hierarchical organization (i.e. less command and control)
 virtual teams, multiple teams, time-writing
 multiple reporting lines – matrixed organization (e.g. functional vs admin.)
 diversity, policy on harassment in the workplace, alcohol & drug use policy
PROJECT PLANNING
Project planning
 Project planning involves breaking down the work into
parts, estimating the time and cost to complete each part
and assigning these to project team members or third
party contractors.
 The Project plan is not perfect from Day 1, but is refined
progressively, as more details emerge to make the
estimates more realistic. (Progressive Elaboration)
 Once a Project Scope has been defined and approved, the
next step is to create a “Work Breakdown Structure”
(WBS)
Project planning
 A WBS is a deliverable-oriented hierarchical decomposition
of the work to be performed.
 Forexample, if you have “Report” as a deliverable, the
work to be performed is:
“Write Report”.
This can be decomposed into:
Create Outline
Write Chapter 1
Write Chapter 2 etc.
WBS CONSIDERATIONS - I
 Level of Decomposition
 Greater details give more clarity and control
 Too much is micro-managing and inefficient
 The 100% Rule
 Nothing Missing - this means that the WBS contains ALL the work
required to do the project (entire scope)
 Nothing Added – no additional tasks outside the Project Scope is added
 The WBS contains ALL the work and ONLY the work required
 Rolling-Wave Planning
 Near term work is more detailed, far out work less detailed
 This is an example of “Progressive Elaboration”
WBS CONSIDERATIONS - II
 A Work Package is a deliverable or project work component
at the lowest level of each branch of the WBS
 Itis the point at which the cost and duration of the work
can be reliably estimated
A Work Package (WP) can be so well defined that it can
be outsourced for a fixed-price contract
108
WBS CONSIDERATIONS - II
 In the House Project WBS example, 1.1.1.1 and 1.1.1.2 and 1.1.1.3 are
Work Packages
109
PROJECT TIME MANAGEMENT
110
Steps in Project Time Management
 Define activities – these are the lowest level, actionable items (WPs)
from decomposed WBS
 Sequence activities – arrange the activities in a logical sequence for
execution – can be expressed as a Network Diagram
 Estimate Activity Resources – determine the types and quantities of
resources required to perform each activity - Resource Breakdown
Structure (RBS)
 Estimate Activity Duration – determine how long each activity will
take to complete, using various estimation techniques
 Develop Schedule – develop the project schedule, using various
scheduling tools and techniques
 Control Schedule – identify critical path activities, consider various
schedule compression techniques
Project Time Management – Sequence Activities
 Sequence activities – arrange the activities in a logical sequence
for execution. This usually entails creating a Network Diagram
A project schedule network diagram shows dependencies such
as predecessors, and successors
112
Project Time Management – Sequence Activities
 PDM is the most common method of representing Scheduling Networks
Sequence Activities - PDM
 PDM shows interrelationships and dependencies among activity nodes
F/S means the predecessor must finish before the successor starts*
S/S means the predecessor must start before the successor can start
F/F means the predecessor must finish before the successor can finish
S/F means the predecessor must start before the successor can finish
*F/S is the most common type of relationship
Sequence Activities - Dependencies
 There are 4 major types (sources) of dependencies:
Estimate Activity Resources
 Estimate Activity Resources – determine the types and quantities of resources
required to perform each activity - Resource Breakdown Structure (RBS)
Estimate Activity Durations
 Estimate Activity Duration – determine how long each
activity will take to complete, using various estimation
techniques
 Estimate effort required to get the job done – usually
expressed in terms of labour units or staff weeks etc.
 Estimate actual duration of the work - usually expressed in
terms of work-days or work-weeks, excluding weekends
and holidays
Example: Tasks(WBS), durations, and dependencies
Task Effort (person- Duration (days) Dependencies
days)
T1 15 10
T2 8 15
T3 20 15 T1 (M1)
T4 5 10
T5 5 10 T2, T4 (M3)
T6 10 5 T1, T2 (M4)
T7 25 20 T1 (M1)
T8 75 25 T4 (M2)
T9 10 15 T3, T6 (M5)
T10 20 15 T7, T8 (M6)
T11 10 10 T9 (M7)
T12 20 10 T10, T11 (M8)
Estimate Activity Durations
 There are several estimating techniques
 Analogous – based on similar work done in the past (duration, budget,
size, weight, and complexity from previous, similar project)
 Parametric – based on some statistical or mathematical model. For
example, to paint a room, you need the know the square footage of the
area to be painted and the volume of each gallon of paint in order to
calculate the number of gallons needed.
 Three-point – used when some level of uncertainty exists to find the
best out of 3 different estimates
 Triangular Distribution – simple average
 Beta Distribution – weighted average (Also known as PERT technique)
 Reserve Analysis – this involves addition of some contingency reserves
into the overall project schedule
 Group decision making - techniques like Brainstorming and DELPHI are
used to gather input from knowledgeable stakeholders and arrive at an
agreeable answer
Estimate Activity Durations - PERT
 PERT – Program Evaluation and Review Technique
 Also called the Beta Distribution Curve
 PERT Estimate = Optimistic + Pessimistic + (4* Most Likely)
6
Develop Project Schedule
 Project Schedules can be displayed using various tools such as:
 Milestone Chart
 Activity Bar Charts (also Gantt Charts). Microsoft Project can be used to create Gantt charts
 Network Diagrams (showing precedence and dependencies)
 Similar to PDM, the Critical Path Method (CPM) is one of the most commonly used for developing
a Project Schedule
 CPM is used to identify time-critical activities
 The Critical Path determines the Overall Project Duration
 If any activity on the Critical Path is delayed, it translates directly to a delay in the Project
 Non-Critical path activities have some float (also known as slack)
 Such activities may experience some delay without adverse effect on the overall project schedule
 There are 3 types of Floats:
 Total Float - The amount of time a task can slip without impacting the project end date
 Free Float – The amount of time a task can slip without impacting the early start of the next task
 Project Float – The time between the Project’s early finish date and the date it is due
Example: Activity Bar Chart
Example of MS Project Gantt Chart
CRITICAL PATH METHOD
 Each Node represents a task, showing the Task ID, Duration, Earliest Start and Finish
times, Latest Start and Finish times, as well as the Float (if any).
Rules for Computing the Critical Path
 Forward Pass – determine ES and EF
 Start from the beginning of the project (left)
 Start the project at Day 0, therefore the ES for the first task = 0
 Add duration to ES to get EF of each task. EF = ES + Duration
 The ES for all successor tasks is the EF for the predecessor task
 If a task has multiple predecessors, the ES is the highest EF of its predecessors
 Backward Pass – determine LS and LF
 Start from the end of the project (right)
 The LF for the last (rightmost) task its EF . This task has no successor.
 Subtract duration from LF to get LS. LS = LF - Duration
 The LF for all predecessor tasks is the LS of the successor
 If a task has multiple successors, the LF is the lowest LS of its successors
 Calculate the Total Float for each task. Float = LS - ES or LF - EF
 Tasks with Zero Floats are on the Critical Path
Computing the Critical Path
Identifying Critical Path Activities
Tasks with Zero Floats are on the Critical Path

Schedule Compression Techniques
 Leads and Lags
 In a Finish to Start activity, if the successor tasks starts before the
predecessor finishes, then there is a Lead time
 If there is a delay in starting the successor activity after the
predecessor has finished, then there is a Lag time.
LEAD
LAG
Schedule Compression Techniques
 There are two major techniques to shorten or compress a project
schedule:
 Fast Tracking
 Applyinglead times to shorten the schedule by performing
some activities in parallel or slightly overlapped, which
normally should be performed in sequence.
 Crashing
 Reducingthe length of the critical path by bringing in

more resources to shorten the duration
Key points to note in Project Time Management
 Estimating the difficulty of a problem is hard, hence the time
(and cost) estimates to solve the problem could be off base.
 Productivity is not proportional to the number of people working
on a task.
 Adding people to a late project could cause further delays
because of communication problems and possible inexperience.
 The unexpected always happens. Always allow contingency in
planning.
PROJECT COST MANAGEMENT
131
Different Types of Cost
 Direct cost - directly linked to doing the work of the project. E.g. cost of
hiring specialised contractors, buying software licences or commissioning your
new building.
 Indirect cost - not specifically linked to your project but part of the cost of
doing business overall. E.g. rent, electricity, staff bus, cost of providing
tea/coffee/snacks
 Fixed cost - one-off charge, not dependent on the size or duration of your
project. E.g. cost of hiring a Project Management Trainer or a Facilitator for
Kick-off meeting
 Variable cost - changes with the duration or size of your project. E.g. salaries
 Sunk cost - has already been incurred whether or not the project progresses.
Usually classified as a loss, especially, if the project is cancelled.
Source: The Money Files Blog by Elizabeth Harrin; ProjectManagement.com

Project Cost Management
 Project cost management includes the processes involved in
estimating, budgeting, and controlling costs so that the project can
be completed within the approved budget:
 Estimate Cost – determine the cost of each activity (WP)
required to project objectives
 Determine Budget – determine the aggregate cost of all Work
Packages required to deliver all project objectives. This process
creates the Budget Baseline
 Control Cost – determine project cost performance, using Earned
Value Management (EVM)
Estimate Project Cost
 This process involves developing an estimation of monetary resources
need to complete the project objectives.
 The estimation is based on the information available at a given point
in time
 In order to achieve optimal cost for the project, consider trade-offs
such as:
 Risk (Risk mitigation - acceptance, avoidance, transfer etc., comes at a
cost)
 Buy versus build
 Lease versus own. (SaaS subscription is a form of Software lease)
 Degree of accuracy increases as the project progresses.
 Price = Cost + Profit (Do not confuse Price with Cost !)
Project Cost Estimation Techniques
 There are 3 main techniques for estimating cost:
 Analogous (aka Experience-based Technique) - based on historical
data, experience. (Top-down)
 Parametric (aka Algorithmic Technique) – applying some algorithm and
formula to some parameters
 Bottom-up – starting from the lowest level of work to be done
(WBS→WP)
Analogous (Experience-based) Technique
 Experience-based techniques rely on judgments based on experience of past projects and the
effort expended in these projects on software development activities.
 Typically, you identify the deliverables to be produced in a project and the different software
components or systems that are to be developed.
 Document these in a spreadsheet, estimate them individually and compute the total effort
required.
 Can be combined with a Group Decision-making technique such as DELPHI.
 Get a group of people involved in the effort estimation and ask each member of the group
to explain their estimate.
 Disadvantages
 A new software project may not have much in common with previous projects.
 Software development changes very quickly and a project may want to take advantage of
newer, but unfamiliar techniques such as web services, application system configuration, HTML
or Java.
 If you have not worked with these techniques, your previous experience may not help you to
estimate the effort required, making it more difficult to produce accurate estimates.
Parametric (Algorithmic) Technique
 In Parametric or Algorithmic Technique, a formulaic approach is used to compute the project
effort based on estimates of product attributes, such as size, and process characteristics – e.g.
experience of staff involved.
 The Estimate is computed as a mathematical function of product, project and process attributes
whose values are estimated by project managers:
 Effort = A  SizeB  M,
 where A is an organisation-dependent constant, B reflects the disproportionate effort for

large projects and M is a multiplier reflecting product, process and people attributes.
 Most models are similar, but they use different values for A, B and M. The most commonly-used
product attribute for Software cost estimation is code size.
 Algorithmic cost models are a systematic way to estimate the effort required develop a system.
 Disadvantages
 These models are usually too complex and difficult to use.
 There are many attributes and considerable scope for uncertainty in estimating their values.
 Only relatively few number of large companies do this in practice, mostly those working in
defense and aerospace systems engineering.
Bottom-up Technique
Modules Design Code Test Train Deploy Evaluate Total

Module 1 $ $ $ $ $ $ $$
Module 2 $ $ $ $ $ $ $$
Module 3 $ $ $ $ $ $ $$
Module 4 $ $ $ $ $ $ $$
Module 5 $ $ $ $ $ $ $$
Module 6 $ $ $ $ $ $ $$
Module 7 $ $ $ $ $ $ $$
Factors affecting Estimation accuracy
 The size of a software system can only be known accurately when it is
finished.
 Several factors influence the final size
 Use of reused systems and components
 Programming language
 Distribution of the system (implementation architecture)
 As the development process progresses then the size estimate
becomes more accurate.
 For Parametric Estimation, estimates of factors contributing to B and
M are subjective and vary according to the judgment of the estimator.
Estimate uncertainty over time
Determine the Budget
 This process involves allocating cost to the work packages (WP) or
individual work items to create a Planned Expenditure (Expected Cashflow)
for the project.
 The Planned Expenditure is the summation of the cost of individual WPs
 The Planned Expenditure + Contingency Reserve is the approved version
of the budget in a time-phased project (Project Baseline Budget)
 The Contingency Reserve is the amount budgeted to handle identified risks
as well as risks not yet identified.
 The Project Baseline Budget will be used to monitor and control the costs
and will also be the source from which variances are measured.
Funding Limit Reconciliation - I
 As a Project Manager, it is not expected that you will go to the
Sponsor or Governance Committee everyday or every week to ask
for money.
 Funding Limit Reconciliation is a mechanism to determine how
much money to ask for and what time period the money is
expected to cover – this keeps planned scope and released fund in
sync.
 Itis highly unlikely (and not good practice) to release funds to
cover the entire budget at the start of the project
 Some organizations use the “Gate Approach” to determine
when portions of the budget is released at what time
Funding Limit Reconciliation - II
 The Funding Limit Reconciliation curve has 3 elements
 Planned Expenditure (Expected Cash Flow) – the cumulative
amount of money the Project Manager expects to spend over the
life of the project.
 ProjectBaseline = Planned Expenditure (expected cash flow) +
Contingency Reserve
 Project Budget is the total budget
 It is the Project baseline + Management Reserve.
 The Project Manager has no authority over the Management Reserve
Funding Limit Reconciliation
Project Cost Baseline = Expected Cash Flow + Contingency Reserve

Project Budget = Project Cost Baseline + Management Reserve
Control Cost
 This process involves monitoring the status of the project to keep it
within budget and to manage changes to the cost baseline
 Cost Control primarily involves:
 Ensuring expenditure does not exceed funding
 Monitoring cost performance and variance from approved cost baseline
 Monitoring work performance against fund expended
 Sometime, cost changes cannot be avoided, hence Cost Control involves:
 Influencing the factors that can cause change to the cost baseline
 Creating cost change requests and getting them approved in a timely manner
 Updating the budget baseline
EARNED VALUE CONCEPT
 Earned Value (EV) is a project tracking tool designed to accurately measure project
progress, using some standard metrics
 Originally designed by the US Government in the 1960s to track large-scale projects, and
formally adopted by the US Department of Defence. It later became an ANSI standard
(ANSI EIA 748-A)
 Earned Value, as the name implies, assigned values to tasks within the project.
 As each task is completed, the value of the task is earned towards the project.
 Once all tasks have been completed, the value of the entire project has been earned
 Earned Value is a project management methodology for integrating scope, schedule
and resources and for objectively measuring project performance and progress
 Performance is measured by determining the budgeted cost of work performed (i.e. the
Earned Value) and comparing it to the actual cost of work performed (i.e. actual cost)
EARNED VALUE MANAGEMENT
PV - Planned Value BCWS – Budgeted Cost of Work Scheduled Value of all work planned to date
EV – Earned Value BCWP – Budgeted Cost of Worked Performed Value of all work completed to date
AC – Actual Cost ACWP – Actual Cost of Work Performed Sum of all cost actually incurred for
completed work. If project is exactly
on budget AC = EV
SV = EV – PV SV = BCWP – BCWS -ve means behind schedule
Schedule Variance +ve means ahead of schedule
SPI = EV/PV SPI = BCWP/BCWS <1 is bad, progressing slower than
Schedule Performance Index (A measure of schedule efficiency – how planned
efficiently the project team is getting work >1 is good, progressing faster than
done) planned
CV = EV – AC CV = BCWP - ACWP -ve means over-budget
Cost Variance +ve means under- budget
CPI = EV/AC CPI = BCWP/ACWP < 1 is bad, getting less value than
Cost Performance Index (A measure of cost efficiency of budgeted work planned (cost overrun)
– the cost efficiency of work completed) >1 is good, getting more value than
planned (cost underrun)
BAC BAC Is the total project budget i.e. PV at
Budget at Completion the end of the project
PROJECT QUALITY MANAGEMENT
PROJECT QUALITY CONCEPTS
 Quality is the degree to which a set of inherent and essential characteristics fulfil
requirements.
 Project Quality Management includes both stated and implied quality expectations.
 Key Quality Concepts
 Customer Satisfaction: Project Manager must both satisfy the customer and also meet
requirements
 Prevention vs Inspection: Quality should be inherently designed into the project, not
inserted after-the-fact via Inspection
 Continuous Improvement: Follow the Plan-Do-Check-Act (PDCA) model to ensure continuous
focus on quality and improvement
 Cost of Quality: this is the cost of conformance or non-conformance to quality requirements
 Cost of conformance is the money spent during the project to avoid failures
 Cost of non-conformance is the money spent during and after the project because of failure
 While working towards good quality, avoid “gold plating” i.e. giving the customer extra
(beyond requirements), just to make the customer happy. This drives up cost unnecessarily.
PROJECT QUALITY CONCEPTS
Cost of Quality
PROJECT QUALITY ASSURANCE
 Quality Assurance is concerned about all aspects of quality. It
includes all processes, activities and actions taken to ensure that
the project or product is as close to being defect-free as possible.
 Quality Assurance is Preventive, while Quality Control (Inspection)
is after-the-fact.
BENEFITS OF PROJECT QUALITY ASSURANCE
 Project Quality Assurance helps improve productivity and customer
satisfaction, while reducing rework and cost.
 It also increases team’s motivation to get it “right-first-time”
 Emphasis is on “self-checking” versus Inspection. Workers
generally prefer to find quality issues themselves and correct via
design, versus those discovered by Auditors and Inspectors
QUALITY VERSUS GRADE
Example:
 A Toyota Corolla and a Lexus might have the same quality if they both have
similar quality standards, such as number of defects per car.
 However, a Lexus is a higher grade car than a Corolla, given its leather
seats, real wood dashboard, front and side airbags etc. while a Corolla may
have cloth fabric seats and plastic dashboard.
 The grade of Lexus determines the market niche it serves – rich people
COMMON QUALITY STANDARDS & PIONEERS
Some Quality Pioneers:

 Walter Shewart – Worked at Western Electric’s Hawthorne Plant. Developed the PDCA (PDSA) model and invented
the Statistical Control Chart
 W. Ed Deming – Colleage of Shewart at Hawthorne Plant. Modified Shewart’s PDCA model Helped Japan become a
Quality leader after WW II. Deming Prize was created in his honour in 1951
 Joseph Juran – Colleague of Shewart at Hawthorne. Focused on fitness for use, i.e. must meet real needs of the
stakeholder (grade versus quality). First to apply Pareto Principles to Quality Issues
 A Feigenbaum. Developed Total Quality Management (TQM) based on Deming’s work.
 Joseph Juran – Colleague of Shewart at Hawthorne. Focused on fitness for use, i.e. must meet real needs of the
stakeholder (grade versus quality). First to apply Pareto Principles to Quality Issues
 Kaoru Ishikawa. Developed the Ishikawa (Fishbone) Diagram for Cause and Effect (Root Cause) Analysis
PDCA is the basis for most of the modern day Project Lifecycle and Quality Management
SEVEN BASIC QUALITY TOOLS
 Cause and Effect Diagram (Fishbone/Ishikawa)
 Flowcharts
 Checklists
 Pareto Diagrams
 Histograms
 Control Charts
 Scatter Diagrams
SEVEN BASIC QUALITY TOOLS – 1 (CAUSE AND EFFECT)
Also known as FISHBONE or ISHIKAWA Diagram

 Breaks down in successive layers, root causes that potentially contribute to a particular effect
 The defect is represented as the Fish head (on the right) and the possible effects extend to the
left as Fish bones.
 Bones branching directly off the backbone are major causes, each may have sub-branches as root
causes, and continue to as many lower levels as required
SEVEN BASIC QUALITY TOOLS – 2 (FLOW CHART)
Flow Chart
 Used for designing and documenting simple processes
 It is a diagrammatic representation of a solution model to a given problem
SEVEN BASIC QUALITY TOOLS – 3 (CHECK SHEET)
Check Sheet (sometimes called as Tally Sheet)

 Used to collect data in real time at the location where the data is generated
 Provides a structured way of collecting quality-related data (what, when, frequency)
SEVEN BASIC QUALITY TOOLS – 4 (PARETO PRINCIPLE)
SEVEN BASIC QUALITY TOOLS – 4 (PARETO CHART)
Pareto Chart principles

 Named after Vilfredo Pareto, it contains both bars and a line graph, where individual values are
represented in descending order by bars, and the cumulative total is represented by the line.
 The left vertical axis is the frequency of occurrence, The right vertical axis is the cumulative
percentage of the total number of occurrences
 The Pareto chart highlights the most important among a large set of factors. In quality control, it
often represents the most common sources of defects or the highest occurring type of defect etc.
SEVEN BASIC QUALITY TOOLS – 5 (HISTOGRAM)
Histogram
 Used to assess the probability distribution of a given variable, by depicting the frequencies of
observations occurring in a given range of values
 Histograms are not the same as bar charts. A histogram is used for continuous data, where the bins
represent ranges of data, while a bar chart is a plot of categorical variables
SEVEN BASIC QUALITY TOOLS – 6 (CONTROL CHART)
Control Chart
 Used to determine whether a process should undergo formal inspection for quality-related problems
 Out-of-control – sample has crossed the outside limits
 Rule of 7 – seven consecutive samples above or below the mean (CL), suggesting a clear trend
 Hugging – Samples have little spread
SEVEN BASIC QUALITY TOOLS – 7 (SCATTER DIAGRAM)
Scatter Diagram (Scatter graph/scatter plot))

 Used to identify the type of relationship (if any) between two quantitative variables
 Typically only illustrates the degree and type of correlation between the variables and not the cause
OTHER QUALITY MEASURES
 Six Sigma - a measure of quality that strives for near perfection.
 Seeks to improve the quality of the output of a process by identifying and
removing the causes of defects and minimizing variability in manufacturing and
business processes
 It’s a disciplined, data-driven approach and methodology for eliminating defects -
driving toward six standard deviations between the mean and the nearest
specification limit in any process
 To achieve Six Sigma, 99.99966% of all opportunities to produce some feature of a
part are statistically expected to be free of defects, i.e. not more than 3.4
defects per million opportunities
 A Six Sigma defect is defined as anything outside of customer specifications.
 Also used to also calculate the upper and lower limits on the control chart
 Lean Sigma (Lean Management) focuses more on eliminating waste and
improving efficiency, whereas Six Sigma focuses on eliminating defects and
reducing variability
OTHER QUALITY MEASURES
 Kaizen or Continuous Improvement
 The Kaizen model can be used for continuous improvement of
both the workflow and processes, focusing on continuous
small improvements.
 In this model, operators mostly look for small ideas which, if
possible, can be implemented almost immediately.
 The goal and preference is to make 100 improvements of 1%
each rather than 1 single improvement of 100%
 May be difficult to apply in traditional project management
environments where there is generally a long lag between
requirements gathering and project implementation.
SOFTWARE TESTING
SOFTWARE TESTING
 Software testing is an investigation conducted to provide
stakeholders with information about the quality of the software
product or service under test.
 Software testing also provides an objective, independent view of
the software to allow the business appreciate and understand
the risks of software implementation.
 Test techniques include the process of executing a program or
application software with the intent of:
 finding software bugs (errors or other defects) and
 verifying that the software product is fit for use
SOFTWARE TESTING
 Objectives of Software Testing are to verify that the system:
 meets the requirements that guided its design and development
 responds correctly to all kinds of inputs (both correct and
incorrect input)
 performs its functions within an acceptable time
 is sufficiently usable
 can be installed and run in its intended environments
 achieves the general result its stakeholders desire.
SOFTWARE TESTING LEVELS
 There are four main levels at which Software Testing is conducted:
 Unit Test, Integration Test, System Test and Acceptance Test
 What is being tested at each Testing level ?
 Unit Testing - the smallest independent and testable part of
the source code is referred to as a unit. It is the first step in
software testing environment and is generally conducted by the
developers or their team mates.
 Integration testing - here the testers check how one or more

units interact with each other and produce output for various
scenarios. This form of testing is carried out by a group of
developers or a specially trained software tester. Unit testing
must have been completed for all units before Integration testing
can be performed meaningfully.
 System Testing – performed once the integration testing has been
completed. The system as a whole with all components well
integrated are tested for performance and adherence to quality
standards. System testing checks for compliance with the functional
and technical specifications, as well as the quality standards defined
by the organization. The test scenario (environment and data) must
be similar to the live scenario where the system will be deployed.
 Acceptance Testing – performed by the quality assurance team and

stakeholder representatives. The system is tested for quality and
accuracy, using predefined test scenarios and test cases. Acceptance
testing looks at the system from various angles: from look-and–feel, to
internal functioning, performance and response time.
TYPES OF ACCEPTANCE TESTING
 User Acceptance testing - carried out by the actual users before
the software is accepted.
 Operation Acceptance testing – carried out by the operations
department (or those who will support the system) to ensure that
all the processes and procedures are in place and the systems can
easily be supported and maintained.
 Contract and regulation acceptance testing - carried out to
ensure that the software is in line with all the necessary
government, legal and safety standards.
 These different Acceptance tests can be conducted separately or
at the same time, with representatives representing all interests,
e.g. end users, IT operations (support, Helpdesk etc.) and legal
OTHER TYPES OF ACCEPTANCE TESTING
 Alpha testing - carried out to ensure that the product is of good
quality and also to prepare the system for beta testing. This form
of testing is performed towards the end of software development
where the system can be tested as a whole. Testing is done from
the point of view of a customer.
 Beta testing – carried out after alpha testing in order to improve
the quality of the product and see that the product works per
customer requirements. It is usually done shortly before official
product launch, where some trusted customers are encouraged to
be “early adopters” and provide feedback.
 Alpha and Beta testing are more commonly used for commercial
software development.
OTHER TESTING CONSIDERATIONS
 A robust Testing plan for major Software Development encompasses the following:
Compatibility Testing is also known as Regression Testing. It ensures that previously developed and tested
software and older versions continue to function well after it was changed or interfaced with the new software.
VERSION CONTROL AND RELEASE MANAGEMENT
 In collaborative Software development, it is important to have a process in
place for storing and tracking changes to documents, programs, applications,
websites and portals.
 This process is called Version Control. There are tools (commercial
software) such as Apache, Visual Studio, CVS etc. for managing Version Control
 Changes are usually identified by a number or letter code, called the
"revision number". For example, an initial version is labelled "revision 1".
 Minor changes are indicated as subsets of that revision e.g. “revision 1.2”.
 If the changes are major and significant, they are labelled with a higher
revision number, e.g. “revision 2”
 Each revision is also associated with a timestamp, including the identity of
the person who either made the change or authorised it
 Version Control allows the configuration management team to revert to a
previous (error free) version, in case of problems with a new version
VERSION CONTROL AND RELEASE MANAGEMENT
 Release Management allows a phased, periodic release of software versions
after undergoing all the required testing.
 New software code is usually progressed from Development to Acceptance to
Production environments. (Acceptance is the same as Test Environment)
 Every major change requires some change management to help users
understand and embrace with the change
 Release Management ensures that end users do not encounter ad-hoc and
unexpected changes (no matter how small) to the software they are already
familiar with
 In Software Development, it is not good practice to immediately release every
single change to production (end users). Changes are usually accumulated until an
opportune time (release cycle) before being pushed into production.
 Most Software companies try to limit major revisions to no more than one or
two per year. A few minor revisions may be released in between as necessary.
Software pricing
180
Software pricing
 Estimates are made to discover the cost (to the developer) of
producing a software system.
You take into account the cost of hardware, software,
travel, training, testing, mobilization and other effort.
 There is no simple relationship between the development cost

and the price charged to the customer.
Broader organisational, economic, political and business
considerations influence the price charged.
181
Factors affecting software pricing - I
Factor Description
Contractual terms A customer may be willing to allow the developer to retain
ownership of the source code and reuse it in other projects. The
price charged may then be less than if the software source code
is handed over to the customer. Ownership of Intellectual
Property also changes if the source Code is handed over to the
customer
Cost estimate If an organization is unsure of its cost estimate, it may increase
uncertainty its price by a contingency over and above its normal profit.
Financial health Developers in financial difficulty may lower their price to gain a
contract. It is better to make a smaller profit or just break even
than to go out of business. Cash flow is 182considered more
important than profit in difficult economic times.
Factors affecting software pricing - II
Factor Description
Market opportunity A development organization may quote a low price
because it wishes to break into a new segment of the
software market. Accepting a low profit on one project
may give the organization the opportunity to make a
greater profit later, after the company has gained visibility
and acceptance. The experience gained may also help it
develop new products.
Requirements If the requirements are likely to change, an organization

volatility may lower its price to win a contract. After the contract is
awarded, high prices can be charged for changes to the
requirements.
183
Pricing strategies
 Under pricing
A company may underprice a system in order to gain a
contract that allows them to retain staff for future
opportunities (Financial Health)
A company may underprice a system to gain access to a
new market area (Market Opportunity)
 Increased pricing
 The price may be increased when a buyer wants a
fixed-price contract and so the seller increases the
price to allow for unexpected risks e.g. higher inflation.
184
Pricing to win
 The software is priced according to what the developer
believes the buyer is willing to pay
 Ifthis is less than the development costs, the
software functionality may be reduced accordingly
with the expectation that extra functionality will
be added at extra cost at a date or future release
 Additionalcosts may be added as the requirements
change and these may be priced at a higher level
to make up the shortfall in the original price
185
Key points to note in Software pricing
 The price charged for a system does not just depend
on its estimated development costs and the profit
required by the development company.
 Organizational factors may dictate that the price
is increased to compensate for increased risk or
decreased to gain competitive advantage.
 Software is often priced to gain a contract and the
functionality of the system is then adjusted to
meet the estimated price.
186
Agile Project Management
187
Traditional (Waterfall) Project Management Recap
188
Source: Project Management Institute (PMI): Agile vs Waterfall Webinar, February 26, 2020
Traditional (Waterfall) Project Management Pros & Cons
189
What is Agile ?
 Agile methods of software development are iterative approaches
where the software is developed and delivered to customers in
increments.
 Agile project management focuses on continuous releases and
incorporating customer feedback with every iteration.
 Unlike traditional, plan-driven (also called Waterfall) approaches,
the functionality of these increments is not planned in advance but
is decided during the development.
 Thedecision on what to include in an increment depends on
progress and on the customer’s priorities.
 The customer’s priorities and requirements change so it makes
sense to have a flexible plan that can accommodate these changes.
190
Agile planning
 Stemming from Toyota's lean manufacturing concept of the 1940s,
software development teams have embraced agile methodologies to
reduce waste and increase transparency while quickly addressing their
customers' ever-changing needs.
 Agile is different from traditional “waterfall” project management that
focuses on "big bang" single software launch/release
 Agile helps software teams collaborate better and innovate faster
than ever before.
 Agile project management can be categorized into two frameworks:
 Scrum (more common) which is focused on fixed-length project
iterations
 Kanban which is focused on continuous releases.
 Upon completion of each iteration or release, the team immediately
moves on to the next.
191
How Scrum works
 Scrum is a framework for agile project management that uses fixed-length
iterations of work, called sprints.
 There are four ceremonies or processes that bring structure to each sprint:
Sprint Planning Sprint Demo Daily Stand-up Retrospective
A team
planning A sharing Also known as a A review of
meeting that meeting where stand-up, a 15- what did and
determines the team shows minute mini- didn't go well
what to what they've meeting for the with actions to
complete in completed in software team make the next
the coming that sprint. to sync. sprint better.
sprint. 192
How Scrum works
 Central to a Sprint is the Backlog - the body of work that needs to be
done. There are 2 backlogs:
 The product backlog (owned by the product owner) which is a
full, prioritized list of features
 The sprint backlog which is populated by taking issues from the
top of the product backlog until the capacity for the next
sprint is reached.
 Scrum teams have unique roles specific to their stake in the process.
 Typically
there is a scrum master, or champion of the scrum
method for the team;
 The product owner, who is the champion of the product;
 The scrum team, who are often cross-functional team members
in charge of getting the work done. 193
How Kanban works
 Kanban is a framework for agile project management that matches the work to
the team's capacity.
 It is focused on getting things done as fast as possible, giving teams the ability
to react to change even faster than scrum.
 Unlike scrum, Kanban has no backlogs. Instead, work sits in the ”To Do”
column. This enables Kanban teams to focus on continuous releases, which can
be done at any time.
 All work is visible, scoped, and ready to execute so that when something is
completed, the team immediately moves on to the next.
 The amount of work is matched to the team's capacity through WIP limits,
which is a predefined limit of work that can be in a single column at one time
(except the To Do column).
194
How Kanban works
 The Kanban framework includes the following four
processes/components:
List of work
Work in Progress Continuous
(or stories) Columns or lanes
Limits (WIP) Releases
“To Do” List
Used on a
List of work, or A rule to limit The team works
Kanban board
stories, are the amount of on the amount
to distinguish
defined as work to be done of stories within
tasks from
issues or tasks based on the the WIP limit
different work
that need to get team's and can release
streams, users,
done. capacity. at anytime.
projects, etc.
195
Agile Events
 Agile projects go through seven events for product development.
 These events are also referred to as stages :
 Project planning: The initial planning for your project. Project
planning includes creating a product vision statement and a product
roadmap, and can take place in as little time as one day.
 Release planning: Planning the next set of product features to release
and identifying an imminent product launch date around which the
team can mobilize. On agile projects, you plan one release at a time.
 Sprint (for SCRUM): A short cycle of development, in which the team
creates potentially shippable product functionality. Sprints, sometimes
called iterations, typically last from one to four weeks. Sprints can
last as little as one day, but should not be longer than four weeks.
Sprints should remain the same length throughout the entire projects.
196
Agile Events (contd.)
 Sprint planning: A meeting at the beginning of each sprint where the
scrum team commits to a sprint goal. They also identify the requirements
that support this goal and will be part of the sprint, and the individual
tasks it will take to complete each requirement.
 Dailyscrum (stand-up): A 15-minute meeting held each day in a sprint,
where development team members state what they completed the day
before, what they will complete on the current day, and whether they
have any roadblocks.
 Sprint review (demo): A meeting at the end of each sprint, introduced by
the product owner, where the development team demonstrates the
working product functionality it completed during the sprint.
 Sprintretrospective: A meeting at the end of each sprint where the
scrum team discusses what went well, what could change, and how to
make those changes. 197
Agile Roadmap
198
Agile Roadmap Stages
 In Stage 1, the product owner identifies the product vision. The product
vision is a definition of what your product is, how it will support your
company or organization’s strategy, and who will use the product. On longer
projects, revisit the product vision at least once a year.
 In Stage 2, the product owner creates a product roadmap. The product
roadmap is a high-level view of the product requirements, with a loose time
frame for when you will develop those requirements. Identifying product
requirements and then prioritizing and roughly estimating the effort for those
requirements are a large part of creating your product roadmap. On longer
projects, revise the product roadmap at least twice a year.
 In Stage 3, the product owner creates a release plan. The release plan
identifies a high-level timetable for the release of working software. An agile
project will have many releases, with the highest-priority features launching
first. A typical release includes three-to-five sprints. Create a release plan at
the beginning of each release. 199
Agile Roadmap Stages
 In Stage 4, the product owner, the scrum master, and the development
team plan sprints, also called iterations, and start creating the product
within those sprints. Sprint planning sessions take place at the start of
each sprint, where the scrum team determines what requirements will be
in the upcoming iteration.
 In Stage 5, during each sprint, the development team has daily meetings.
In the daily meeting, you spend no more than 15 minutes to discuss what
you completed yesterday, what you will work on today, and any roadblocks
you have.
 In Stage 6, the team holds a sprint review (demo). In the sprint review, at
the end of every sprint, you demonstrate the working product created
during the sprint to the product stakeholders.
 In Stage 7, the team holds a sprint retrospective. The sprint retrospective
is a meeting where the team discusses how the sprint went and plans for
improvements in the next sprint. Like the sprint review, you have200 a sprint
retrospective at the end of every sprint.

Agile Progress Tracking
 Agile project teams often use six main deliverables, to develop products and track
progress:
 Product vision statement: An elevator pitch, or a quick summary, to communicate
how your product supports the company's or organization's strategies. The vision
statement must articulate the goals for the product.
 Product backlog: The full list of what is in the scope for your project, ordered by
priority. Once you have your first requirement, you have a product backlog.
 Product roadmap: The product roadmap is a high-level view of the product
requirements, with a loose time frame for when you will develop those
requirements.
 Release plan: A high-level timetable for the release of working software.
 Sprint backlog: The goal, user stories, and tasks associated with the current sprint.
 Increment: The working product functionality at the end of each sprint.
201
Agile Project Management Roles
 Development team: The group of people who do the work of
creating a product. Programmers, testers, designers, writers, and
anyone else who has a hands-on role in product development is a
member of the development team.
 Product owner: The person responsible for bridging the gap
between the customer, business stakeholders, and the development
team. The product owner is an expert on the product and the
customer's needs and priorities. The product owner works with the
development team daily to help clarify requirements. The product
owner is sometimes called a customer representative.
 Scrum master: The person responsible for supporting the
development team, clearing organizational roadblocks, and keeping
the agile process consistent. A scrum master is sometimes called a
project facilitator. 202
Agile Project Management Roles (contd.)
 Stakeholders: Anyone with an interest in the project. Stakeholders
are not ultimately responsible for the product, but they provide input
and are affected by the project's outcome. The group of stakeholders
is diverse and can include people from different departments, or even
different companies.
 Agile mentor: Someone who has experience implementing agile
projects and can share that experience with a project team. The agile
mentor can provide valuable feedback and advice to new project
teams and those that want to perform at a higher level.
203
Other considerations for Agile planning
 Challenges
 Agile planning is reliant on customer involvement and
availability.
 This can be difficult to arrange, as customer representatives
sometimes have to prioritize other work and are not
available for the planning game.
 Furthermore, some customers may be more familiar with
traditional project plans and may find it difficult to fully
engage in an agile planning process.
204
Other considerations for Agile planning
 Applicability
 Agileplanning works well with small, stable development
teams that can get together and discuss the stories to be
implemented.
 However, where teams are large and/or geographically
distributed, or when team membership changes
frequently, it is practically impossible for everyone to be
involved in the collaborative planning that is essential
for agile project management.
205
Agile Software delivery
 A software increment is always delivered at the end of
each project iteration.
 If the features to be included in the increment cannot be
completed in the time allowed, the scope of the work is
reduced.
 The delivery schedule is never extended.
206
A manifesto for Agile Software Developers
 The Agile Software Development Manifesto© is an intentionally
streamlined expression of the core values of agile project
management. Use this manifesto as a guide to implement agile
methodologies in your projects.
"We are uncovering better ways of developing software by doing it and
helping others do it. Through this work, we have come to value:
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
That is, while there is value in the items on the right, we value the
items on the left more."
©Agile Manifesto Copyright 2001: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning,
207 Jim Highsmith,
Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas.
This declaration may be freely copied in any form, but only in its entirety through this notice.
What is different with Agile Methodology
208
12 Principles of Agile Development
 The 12 Agile Principles are a set of guiding concepts that
support project teams in implementing agile projects
1. The highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile
processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple
of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the
project.
5. Build projects around motivated individuals. Give them the environment
and support they need, and trust them to get the job done.
209
12 Principles of Agile Development
6. The most efficient and effective method of conveying information to and within
a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers,
and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity, which is the art of maximizing the amount of work not needed to be
done, is essential.
11. The best architectures, requirements, and designs emerge from self-organizing
teams.
12. At regular intervals, the team reflects on how to become more effective, then
fine-tunes and adjusts its behaviour accordingly.
210
Benefits of Agile Development
211
When to use Agile vs Waterfall
212
End of CSC 421 Lecture Notes
213

CSC 416 - 421 Notes

Uploaded by

Copyright:

Available Formats

You might also like

CSC 416 - 421 Notes

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

CSC 416 - 421 Notes

Uploaded by

Copyright:

Available Formats

CSC 416/421

Software Project Management

 Software Engineering by Ian Sommerville [10th Edition, 2015]

 Software Project Management by Bob Hughes and Mike Cotterell

 Guide to Project Management Body of Knowledge

 Project – a temporary endeavour undertaken to create a unique product,

 A project - a unique set of activities meant to produce a defined

 Project Management – the application of knowledge, skills, tools and

 These factors influence an organization’s ongoing operations and business strategies.

 Phases overlap and could be iterative (progressive elaboration)

T-shirts, Face caps,

Stakeholder UNAWARE RESISTANT NEUTRAL SUPPORTIVE CHAMPIONS

Steering Project Subject Matter Training Suppliers /

The PMBOK® GuideAgile (6th Edition) lists the following as Project

Developing a Project Scope is a “Planning”, “Definition”, or “Inception” Activity

SOW = Statement of Work

 Watch this → https://youtu.be/voR0FBnC2ZU

 Risk Probability can be similarly scaled

Estimation The time required to develop the software is underestimated.

People It is impossible/difficult to recruit staff with the skills required.

Tools The code generated by software code generation tools is inefficient.

Assign tasks and leadership positions, based on demonstrated personality types

 Get the team together physically as soon possible after formation -

 Leverage the best communication technologies - Developments in

 Agree on a shared language. Virtual teams often also are cross-cultural

 Don’t forget the one-on-ones. Leader should regularly communicate with

 Promote self-leadership across the team. Beyond social skills, managers

 Foster a “global culture.” With a global mind-set, people see themselves

Tasks with Zero Floats are on the Critical Path

 Reducingthe length of the critical path by bringing in

Source: The Money Files Blog by Elizabeth Harrin; ProjectManagement.com

 where A is an organisation-dependent constant, B reflects the disproportionate effort for

Modules Design Code Test Train Deploy Evaluate Total

Project Cost Baseline = Expected Cash Flow + Contingency Reserve

Some Quality Pioneers:

Also known as FISHBONE or ISHIKAWA Diagram

Check Sheet (sometimes called as Tally Sheet)

Pareto Chart principles

Scatter Diagram (Scatter graph/scatter plot))

 Integration testing - here the testers check how one or more

 Acceptance Testing – performed by the quality assurance team and

 There is no simple relationship between the development cost

Requirements If the requirements are likely to change, an organization

Sprint Planning Sprint Demo Daily Stand-up Retrospective

retrospective at the end of every sprint.

You might also like