Software Project Management

Study Guide & Exam Summary

SODM401 / SFEN301 — Software Engineering

This guide covers four topics: Project Management, Risk Management, Managing People, and Teamwork.
Key terms are bolded and exam tips are highlighted throughout — use these to focus your revision.

Section Topic

1 Software Project Management — Overview & the 4 Ps

2 Project Managers, Stakeholders & Leadership (MOI Model)

3 Manager's Responsibilities, Motivation & Success Criteria

4 Scheduling & Planning

5 Resource Leveling & Gantt Charts

6 What Makes Software Management Different

7 Universal Management Activities

8 Risk Management — Classification & Process

9 Risk Identification, Analysis, Planning & Monitoring

10 Managing People — Factors & Motivation Theory

11 Personality Types & Case Study (Alice & Dorothy)

12 Teamwork — Group Cohesiveness & Composition

13 Group Organization & Communication

14 Key Points Recap

 1. Software Project Management — Overview & the 4 Ps
Definition: Project management is concerned with activities that ensure software is delivered on time, on
schedule/budget, and in accordance with the organisation's requirements.
Project management is needed because software development is always subject to budget and schedule
constraints set by the organisation developing the software.

The 4 Ps of Project Management

• People — the most important element of a successful project
• Product — the software to be built
• Process — the framework activities and software engineering tasks needed to get the job done
• Project — all the work required to make the product a reality
Exam Tip: You may be asked to list and define the 4 Ps — memorize the order People → Product → Process →
Project.

2. Project Managers, Stakeholders & Leadership

Management vs. Leadership
• Management = using tools and techniques.
• Leadership = inspiring people to do the right thing.
• Key rule: Leadership with poor management can still succeed; management with poor leadership will
fail.

Stakeholders (people are stakeholders too)

• Senior managers — define business issues with significant influence on the project.
• Project (technical) managers — plan, motivate, organize, and control the practitioners doing the
software work.
• Practitioners — deliver the technical skills needed to engineer the product; often make poor team
leaders.
• Customers — specify requirements; other peripheral stakeholders also exist.
• End-users — interact with the software once it is released for production use.
Your job (as team leader) is to organize and bring value from these people.

The MOI Model (job as team leader)

• Motivation — the ability to encourage (by “push or pull”) technical people to produce to their best
ability.
• Organization — the ability to mold existing processes (or invent new ones) to translate the initial
concept into a final product.
• Ideas / Innovation — the ability to encourage people to create and feel creative, even while working
within set bounds.
Exam Tip: MOI = Motivation, Organization, Ideas/Innovation. This is a classic short-answer question.
 3. Manager's Responsibilities, Motivation & Success Criteria
Your job as a manager — make sure these happen:
• Formal risk management
• Empirical cost and schedule estimation
• Metrics-based project management (tracking work done, costs, work remaining)
• Defect tracking against quality targets
• People-aware project management

Motivating People
• Use monetary rewards cautiously.
• Use intrinsic rewards: recognition, achievement, the work itself, responsibility, advancement, chance
to learn new skills.

Success Criteria for a Project

• Deliver the software to the customer at the agreed time.
• Keep overall costs within budget.
• Deliver software that meets the customer's expectations.
• Maintain a coherent and well-functioning development team.

4. Scheduling & Planning

Scheduling
• One of the most important things you can do — and one of the first things you should do.
• Common tools: Microsoft Project, [Link], [Link].

Planning
• The bad news: time flies. The good news: you're the pilot!
• You must begin planning immediately, even with limited information.
• Approach: plan anyway, then revise as more information becomes available.

Creating a Plan — Things to Know (Scope)

• Context — how the software fits into a larger system/business context and what constraints this
imposes.
• Information objectives — what customer-visible data objects are produced as output, and what data
objects are required as input.
• Function and performance — what function transforms input into output; any special performance
characteristics.
Software project scope must be unambiguous and understandable at both the management and technical
levels.

Creating a Plan — Things to Do (Problem Decomposition)

• Also called partitioning or problem elaboration.
• Once scope is defined, it is decomposed into: constituent functions, OR user-visible data objects, OR a
set of problem classes.
• Decomposition continues until all functions/problem classes are defined (won't be complete early in the
project).

5. Resource Leveling & Gantt Charts

Resource Leveling
A process to examine a project for an unbalanced use of people and resolve over-allocations or conflicts.
Happens when multiple tasks are scheduled at the same time for the same person.
Solutions:
• Make tasks sequential by introducing “fake” dependencies.
• Split resource usage among tasks (e.g., 50% on task 1, 50% on task 2).
Auto resource leveling: Some tools (e.g., Microsoft Project, Jira, Trello) do this automatically — ensuring no
person works over 100% of the time without introducing fake dependencies.

Gantt Charts
A visual bar-chart schedule showing tasks, durations, and dependencies over a timeline (e.g., Design Phase,
Finance Phase, Production Phase, Marketing/Sales, Distribution). Used to find the critical path of a project.
Exam Tip: Know the difference between manual resource leveling (fake dependencies/splitting) vs. auto
resource leveling (tool-managed).

6. What Makes Software Management Different

Software Management Distinctions
• The product is intangible — software cannot be seen or touched; managers can't see progress just
by looking at the artefact.
• Many software projects are 'one-off' projects — large projects usually differ from previous ones, so
even experienced managers may struggle to anticipate problems.
• Software processes are variable and organization-specific — we cannot reliably predict when a
process will lead to development problems.

Factors Influencing Project Management

• Company size
• Software customers
• Software size
• Software type
• Organizational culture
• Software development processes
These factors mean project managers in different organizations may work in quite different ways.
 7. Universal Management Activities
• Project planning — planning, estimating, scheduling development, and assigning people to tasks.
• Risk management — assessing risks that may affect a project, monitoring them, and acting when
problems arise.
• People management — choosing people for the team and establishing effective ways of working.
• Reporting — reporting progress to customers and to company management.
• Proposal writing — the first stage of a project may involve writing a proposal to win a contract,
describing objectives and how the work will be carried out.
 8. Risk Management — Classification & Process
Definition: Risk management is concerned with identifying risks and drawing up plans to minimise their
effect on a project. It is important because of the inherent uncertainties in software development: loosely
defined requirements, requirements changes, difficulty estimating time/resources, and differing individual
skills.

Risk Classification — Two Dimensions

• Type of risk — e.g., technical, organizational, etc.
• What is affected by the risk:
• Project risks — affect schedule or resources.
• Product risks — affect the quality or performance of the software being developed.
• Business risks — affect the organisation developing or procuring the software.

Examples of Project, Product, and Business Risks

Risk Affects Description

Staff turnover Project Experienced staff will leave the project before it is finished.

Management change Project A change of organizational management with different priorities.

Hardware unavailability Project Essential hardware will not be delivered on schedule.

Requirements change Project & product More changes to requirements than anticipated.

Specification delays Project & product Specifications of essential interfaces are not available on
schedule.

Size underestimate Project & product The size of the system has been underestimated.

CASE tool Product Supporting CASE tools do not perform as anticipated.

underperformance

Technology change Business Underlying technology is superseded by new technology.

Product competition Business A competitive product is marketed before the system is

completed.

The Risk Management Process (4 stages)

• Risk identification → produces a list of potential risks.
• Risk analysis → produces a prioritized risk list.
• Risk planning → produces risk avoidance and contingency plans.
• Risk monitoring → produces risk assessment (feeds back into risk analysis).
Exam Tip: This is a cyclical process — risk monitoring loops back into risk analysis, not a one-time checklist.

9. Risk Identification, Analysis, Planning & Monitoring

Risk Identification
May be a team activity or based on the project manager's experience. A checklist of common risk categories
can help:
• Technology risks
• Organizational risks
• People risks
• Requirements risks
• Estimation risks
• Tool risks

Risk Analysis
Assess the probability and seriousness of each risk.
• Probability: very low, low, moderate, high, or very high.
• Consequences: catastrophic, serious, tolerable, or insignificant.
Sample: 'It is impossible to recruit staff with the skills required' = High probability, Catastrophic effect. 'The
time required is underestimated' = High probability, Serious effect.

Risk Planning
Consider each risk and develop a strategy:
• Avoidance strategies — reduce the probability the risk will arise.
• Minimization strategies — reduce the impact of the risk on the project/product.
• Contingency plans — plans to deal with the risk if it does arise.
Example strategies: financial-problem risk → prepare a briefing document for senior management; staff illness
→ reorganize the team so work overlaps; requirements changes → maximize information hiding in the design.

Risk Monitoring
Regularly assess whether each identified risk is becoming more or less probable, and whether its effects have
changed. Each key risk should be discussed at management progress meetings.
Risk indicators include: failure to meet schedule (estimation), organizational gossip (organizational), poor staff
morale (people), many change requests (requirements), late hardware delivery (technology), reluctance to
use tools (tools).
 10. Managing People — Factors & Motivation Theory
People are an organisation's most important assets. Management tasks are essentially people-oriented —
poor people management is a major contributor to project failure.

People Management Factors

• Consistency — treat all team members comparably, without favourites or discrimination.
• Respect — different members have different skills; respect those differences.
• Inclusion — involve all team members; make sure everyone's views are considered.
• Honesty — always be honest about what is going well and what is going badly.

Motivating People
Motivation = organizing work and the working environment to encourage people to work effectively.
Unmotivated people work slowly, make more mistakes, and don't contribute to broader team/organizational
goals.
Types of need behind motivation:
• Basic needs (food, sleep, etc.)
• Personal needs (respect, self-esteem)
• Social needs (being accepted as part of a group)

Human Needs Hierarchy (Maslow)

From bottom to top: Physiological → Safety → Social → Esteem → Self-realization needs.
In software groups, basic physiological/safety needs are usually not an issue. Focus is on:
• Social — communal facilities; informal communication (e.g., social networking).
• Esteem — recognition of achievements; appropriate rewards.
• Self-realization — training (people want to learn more); responsibility.
Exam Tip: Be ready to draw/label the needs hierarchy pyramid and match each level to a workplace example.

11. Personality Types & Case Study

Three Personality/Motivation Types
• Task-oriented — motivated by the work itself (common in software engineering).
• Self-oriented — work is a means to an end (e.g., getting rich, personal success/recognition).
• Interaction-oriented — motivated by the presence and actions of co-workers; they like going to work
to be with people.
Individual motivation is a mix of all three, and the balance can shift with personal circumstances and external
events. An effective group needs a balance of all types — too many of one type causes problems (e.g., all
self-oriented = everyone wants to be the boss).

Case Study: Alice, Dorothy & the Assistive Technology Project

Alice leads a 6-person team building a peer-to-peer messaging system on digital televisions. Dorothy (a
hardware expert) starts coming in late, her work quality drops, and she stops communicating. Alice talks to the
team informally first, then speaks directly with Dorothy.
Root cause: Dorothy lost interest because the chosen product direction gave her no opportunity to use her
hardware interfacing skills — she was working as a plain C programmer and worried about her future
employability.
Lessons / Resolution:
• Unresolved unacceptable work causes other team members to become dissatisfied, feeling they
carry an unfair share.
• Personal difficulties affect motivation because people can't concentrate — they need time and
support, but still have responsibility to their employer.
• Alice's fix: gave Dorothy more design autonomy and arranged training courses to improve her future
opportunities.

Group Composition Example (from the case study)

Person Type

Alice Self-oriented

Brian Task-oriented

Bob Task-oriented

Carol Interaction-oriented

Dorothy Self-oriented

Ed Interaction-oriented

Fred Task-oriented
 12. Teamwork — Group Cohesiveness & Composition
Most software engineering is a group activity — non-trivial projects can't be completed by one person alone.
A good group is cohesive with team spirit; members are motivated by group success as well as personal
goals. Group interaction is a key determinant of group performance, though managers have limited flexibility
in group composition.

Group Cohesiveness — Advantages

• Group quality standards can be developed collectively.
• Members learn from each other; ignorance-based inhibitions are reduced.
• Knowledge is shared; continuity is maintained if a member leaves.
• Refactoring and continual improvement are encouraged — the group fixes problems together,
regardless of who originally wrote the code.
Example: Alice builds team spirit through involving members in specification/design, monthly informal lunches
(sharing news and updates), and periodic 'away days' for technology updating and social interaction.

The Effectiveness of a Team Depends On:

• The people in the group — need a mix of skills (negotiation, programming, testing, documentation).
• The group organization — organized so individuals contribute to the best of their abilities and tasks
are completed as expected.
• Technical and managerial communications — good communication between members and with
external stakeholders.

Assembling a Team — Real-world Constraints

• Project budget may not allow highly-paid staff.
• Staff with appropriate experience may not be available.
• The organisation may want to develop employee skills on the project.

Group Composition Problems (single-type groups)

• All task-oriented — everyone wants to do their own thing.
• All self-oriented — everyone wants to be the boss.
• All interaction-oriented — too much chatting, not enough work.
An effective group has a balance of all types; this is hard since software engineers tend to be task-oriented.
Interaction-oriented people are valuable because they detect and defuse tensions.

13. Group Organization & Communication

Key Organizational Questions
• Should the project manager also be the technical leader?
• Who makes critical technical decisions, and how?
• How are interactions with external stakeholders/senior management handled?
• How can non-co-located people be integrated?
• How can knowledge be shared across the group?

Group Structures
• Small groups — usually organised informally, without rigid structure.
• Large projects — may use a hierarchical structure with different groups responsible for different
sub-projects.
• Agile development — always based on an informal group, since formal structure inhibits information
exchange.

Informal Groups
• The group acts as a whole and reaches consensus on decisions.
• The group leader is the external interface but doesn't allocate specific work items.
• Work is discussed by the whole group; tasks are allocated by ability and experience.
• Works best when all members are experienced and competent.

Group Communications — Factors

• Group size — the larger the group, the harder it is to communicate.
• Group structure — communication is better in informal groups than hierarchical ones.
• Group composition — better with mixed personality types and mixed-sex groups rather than
single-type/single-sex.
• Physical work environment — good workplace organisation encourages communication.
Exam Tip: Communication quality is affected by size, structure, composition, and environment — a common
list-based exam question.

14. Key Points Recap

• Good project management is essential for on-schedule, on-budget software delivery.
• Software management differs from other engineering management: software is intangible, projects are
often novel/one-off, and processes are less mature than traditional engineering.
• Risk management = identifying and assessing risks (probability + consequences), then planning to
avoid, minimise, or handle them via contingency plans.
• People management = choosing the right people and organizing the team and its working environment.
• People are motivated by interaction with others, recognition from management/peers, and opportunities
for personal development.
• Software development groups should be small and cohesive. Effectiveness depends on the people,
group organization, and communication.
• Group communication is influenced by: status of members, group size, gender composition,
personalities, and available communication channels.

End of Study Guide — Good luck with your test!