Week 1: Introduction to Software Project Management

What is a Project?
A project is a planned piece of work or an activity 1that has a specific purpose2.
What makes something a project is that it's both temporary and unique3.
• Temporary means it has a defined beginning and a defined end4.
• Unique means it's not a routine, everyday operation5.
Example: Building a new website for a client is a project. It has a start date, an end
date, and a specific goal. In contrast, performing daily server maintenance is an
operation because it's a routine, ongoing task.
Projects also have other distinct characteristics:
• They involve non-routine tasks6.
• They require planning7.
• They have specific goals to meet8.
• They have a pre-determined time span9.
• They usually involve people from different specialisms (like designers,
coders, and marketers)10.
What is Project Management?
Project management is the practice of initiating, planning, executing, controlling,
and closing the work of a team 11to achieve all the project's goals 12within the
given constraints (like time, budget, and scope)13.
What is Software Project Management (SPM)?
SPM is just a sub-discipline of project management that focuses specifically on
planning, implementing, monitoring, and controlling software projects14.
It's especially important because:
 1. A lot of money is at stake in software projects15.
2. Studies show that many software projects fail16.
3. The most common reason for these failures is bad management17.
Why are Software Projects Different?
Software projects are often harder to manage than other projects (like
construction) for four key reasons18:
1. Invisibility: You can't "see" software. With a bridge, you can see the
progress. With software, it's hard to see how "done" it is just by looking at
it19.
2. Complexity: Software is often extremely complex, with many logical parts
that are tightly interconnected20.
3. Conformity: Software has to conform to the rules of the hardware,
operating systems, and other software it runs with21.
4. Flexibility: People often think software is easy to change ("flexible")22. This
leads to a constant stream of change requests, which can derail the project.
Who are Stakeholders?
Stakeholders are any people who have a "stake" or interest in the project23. It's
crucial to identify them early24.
Example: For a new college payroll system, stakeholders would include:
• Internal to the project: The project manager, the developers25.
• External to the project (but in the organization): The finance department,
the HR department, and the college management26.
• External to the organization: The government (for tax reporting) and the
bank processing the payments27.
The Business Case
This is the document that provides the justification for starting the project28. It
shows that the project's benefits are expected to be greater than its costs29.
Example: A business case might state, "By building a new e-commerce website
[the cost], we can reach customers all over the world, which will increase our sales
and profits [the benefit]"30.
The project manager's job is to protect this business case, making sure costs don't
get too high 31or that features aren't cut to the point where the benefits can't be
realized32.
The Project Charter
This is the high-level document that officially authorizes the project to start and
gives it permission to use resources33. It's a short document that acts as a guide
for the entire project34.
It typically includes:
• The project's main objectives35.
• The start and expected completion dates36.
• A list of important stakeholders37.
• An overview of the budget and resources38.
• A list of major risks39.
Project Management Life Cycle
This is the sequence of phases a project goes through from start to finish.
1. Project Initiation: This is the first phase, where the project is investigated
and understood40. You figure out the scope 41, costs 42, and benefits43. This
leads to a feasibility study 44and the business case45. If it's approved, the
project charter is written46.
2. Project Planning: The project manager creates all the detailed plans 47,
including the project plan (tasks and schedule) 48, the resource plan (who
 does what) 49, the financial plan (budget) 50, the quality plan 51, and the risk
plan52.
3. Project Execution: This is where the team does the work and builds the
product according to the plan53. This phase also includes monitoring and
control to ensure the project stays on track54.
4. Project Closure: This is the final phase. It involves releasing all deliverables
to the customer 55, releasing the project resources 56, and performing a
"post-implementation review" to capture lessons learned for future
projects57.

Week 2: PMI and the PMBOK

What is PMI?
PMI stands for the Project Management Institute58. It's a non-profit organization
for project management professionals around the world59.
PMI is important because it's the organization that gives out the PMP (Project
Management Professional) credential, which is a globally recognized certificate
for project managers60. PMI also oversees the PMBOK Guide61.
What is PMBOK?
PMBOK stands for the Project Management Body of Knowledge62. It's not just a
book; it's the entire collection of processes, best practices, and terms that are
accepted as standards in the project management industry63.
PMI captures this knowledge in a book called "A Guide to the Project
Management Body of Knowledge (PMBOK Guide)"64. This guide is updated
regularly as the industry grows and discovers new best practices65656565.
The Five Process Groups
The PMBOK framework organizes the project lifecycle (from Week 1) into five
standard groups:
 1. Initiating: This is where you define a new project or a new phase 66and get
authorization to start67.
o Key Outputs: Project Charter 68, Feasibility Study 69, Stakeholder
List70.
2. Planning: This is where you define the project's scope 71and create the
detailed plan of action to achieve the project's goals72. This includes
creating a schedule 73and a budget74.
o Key Outputs: Project Management Plan 75, Work Breakdown
Structure (WBS) 76, Schedule 77, Budget78.
3. Executing: This is where you coordinate people and resources to complete
the actual work defined in the plan797979797979797979. This also includes quality
assurance 80and team management81818181.
o Key Outputs: The deliverables (the actual product being built) 82,
change requests83.
4. Monitoring & Controlling: This group happens at the same time as
Executing. It involves tracking, reviewing, and regulating the project's
progress84. This is where you manage changes, report on status 85, and
control the scope, schedule, and costs86.
o Key Outputs: Progress and Status Reports 87, Plan Updates 88, Change
Requests89.
5. Closing: This is where you finalize all activities to formally close the
project90. This includes getting formal acceptance from the customer 91,
releasing the team and resources 92, and archiving all project documents93.
o Key Outputs: The final work products 94, a Certificate of Completion
or Closeout Report95.
The Ten Knowledge Areas
These are the 10 core skill sets a project manager must have to manage a project
well96. These skills are applied across all five process groups.
1. Project Integration Management: This is the "master" area that identifies,
defines, and coordinates all the other project activities97. It's the "glue" that
holds the project together.
2. Project Scope Management: This is about defining exactly what work is
included in the project—and what isn't98.
3. Project Time Management: This involves all the tasks needed to manage
the project's schedule, like estimating how long activities will take and
sequencing them99.
4. Project Cost Management: This is where you estimate costs and create the
budget100.
5. Project Quality Management: This involves planning and tracking the
quality requirements for the project's deliverables to ensure they are not
faulty101.
6. Project Human Resources Management: This is all about managing the
project team, including how they are acquired, developed, and utilized102.
7. Project Communications Management: This defines how, when, and who
will send and receive information throughout the project103.
8. Project Risk Management: This involves identifying potential risks,
assessing their impact, and planning how to respond if they happen104.
9. Project Procurement Management: This manages the process of acquiring
goods or services from outside the project team (e.g., buying hardware or
hiring a contractor)105.
[Link] Stakeholder Management: This is about identifying all stakeholders
and creating a plan to satisfy their needs and expectations106106106106.
 Week 3: Project Evaluation
Why Evaluate Projects?
An organization might have many great project ideas but only enough money or
staff for a few of them107. Managers need a way to evaluate and compare these
projects to decide which ones to select108.
Project Portfolio Management
A Project Portfolio is an overview of all the projects an organization is currently
doing or considering109.
Project Portfolio Management is the process of:
• Identifying which project proposals are worth doing110.
• Prioritizing how to share limited resources (like money and people)111.
• Assessing the risk of potential projects112.
• Making sure different projects aren't duplicating work113.
Evaluating Individual Projects
• Technical Assessment: This is the first check. It asks: "Can we actually build
this?" It evaluates whether the required functionality can be achieved with
current, affordable technology114.
• Cost-Benefit Analysis: This is done to find the best project among several
options115. It involves two steps116:
1. Identify all the costs and benefits117.
2. Express them in common units (like money) to calculate the net
benefit118.
Cost-Benefit Evaluation Techniques
These are specific methods used to compare projects.
• Cash Flow Forecasting: A prediction of when money will be spent
(expenditure) and earned (income) during the project's life119.
• Net Profit: The simplest technique. It's the total income minus the total
costs over the life of the project120.
o Example: Project A costs $100k and brings in $150k. Its net profit is
$50k121. Project B costs $1M and brings in $1.1M. Its net profit is
$100k122. Based only on net profit, Project B looks better.
• Payback Period: The time it takes for a project to "break even" or pay back
the initial investment123. A shorter payback period is usually preferred124.
o Example: Project A costs $100k. It earns $50k in Year 1 and $50k in
Year 2. Its payback period is 2 years. Project B costs $100k and earns
$20k per year. Its payback period is 5 years. Project A is better by this
measure.
• Return on Investment (ROI): This compares the profit to the investment125.
o Formula: $ROI = (Average Annual Profit / Total Investment) * 100$126.
• Net Present Value (NPV): This is a more advanced technique that takes into
account when you get your money127.
o Core Idea: Receiving $100 today is better than receiving $100 next
year, because you could have put today's $100 in a bank and earned
interest on it128.
o How it works: It uses a "discount rate" (like 10%) 129 to calculate the
"present value" of all future cash flows. All the discounted values are
then added up to get the Net Present Value130. A project with a
positive NPV is considered a good investment.
 Week 4: An Overview of Project Planning
Step Wise Project Planning
This is a framework that gives you a set of basic steps to follow when planning a
project131.
Here is an overview of the 10 steps:
• Step 0: Select Project
o This is "Step 0" because it happens before the main project
planning132. It involves evaluating the project (like in Week 3) to
confirm it has priority over other projects133. This is part of project
portfolio management134.
• Step 1: Identify Project Scope and Objectives
o Clearly define the project's goals and how you will measure
success135.
o Identify all stakeholders and their interests136.
o Establish the "project authority" (the person or group in charge)137.
• Step 2: Identify Project Infrastructure
o Understand the project's relationship to the company's overall
strategic plan138.
o Identify any standards or procedures you must follow (e.g., "All new
projects must use our standard security protocols")139.
• Step 3: Analyze Project Characteristics
o Is this a product-driven project (e.g., "Build this app") or an
objective-driven project (e.g., "Find a way to reduce customer
complaints")?140.
o Identify high-level project risks141.
o Select the best development methodology (like Waterfall or Agile)142.
• Step 4: Identify Project Products & Activities
o List all the "products" (deliverables) the project will create143.
o Create an "ideal activity network" showing all the tasks needed to
create those products144.
• Step 5: Estimate Effort for Each Activity
o Estimate the effort (e.g., in person-hours or person-days) for each
individual activity145. This is often a "bottom-up" estimate (see Week
6).
• Step 6: Identify Activity Risks
o Now, look for risks at a more detailed, activity-level146.
o Example from slide: Brigette identifies a risk that "key staff might be
on holiday" during the "investigate user requirements" activity147.
o You then plan how to reduce these risks (e.g., schedule the activity
before the holiday period) 148and adjust your plan149.
• Step 7: Allocate Resources
o Assign specific resources (people, teams, equipment) to each
activity150.
o You may have to revise your plan if resources are limited (e.g., your
best developer can't work on two tasks at the same time)151.
• Step 8: Review/Publicize Plan
o Review the quality of the final plan152.
o Document the plan and get formal agreement from stakeholders153.
• Steps 9 & 10: Execute Plan / Lower Level Planning
o As the project starts, you will need to re-plan later stages in greater
detail as more information becomes available154. Planning is an
iterative process155.
 Week 5: Selection of an Appropriate Project Approach

Build or Buy?
This is one of the first big decisions: should you build the software yourself or get
it from somewhere else?
• In-house: The software is developed by people within the same
organization that will use it156.
• Outsourced: The organization pays a different organization to develop the
software157.
• Off-the-shelf (OTS): You buy a ready-made software product158.
Why Outsource?
• It takes time to develop software in-house159.
• You might need to hire new technical staff for the project 160that you won't
need after the project is finished161.
Advantages of Off-the-Shelf (OTS):
• Cheaper: The supplier spreads the development cost across many
customers162.
• Exists now: There's no development delay 163, and you can often trial the
software before buying164.
• More stable: Existing users have likely already found and reported most of
the bugs165.
Disadvantages of Off-the-Shelf (OTS):
• No competitive advantage: All your competitors can buy the same
software166.
• You must adapt: Your organization may have to change the way it works to
fit the software167.
 • No control: You don't own the code and cannot change it168.
Analyzing Project Risks
The more uncertainty a project has, the higher the risk that it will be
unsuccessful169. Recognizing uncertainty early allows you to plan for it170.
• Product uncertainty: How well are the requirements understood?
171
Sometimes the users themselves are uncertain about what they want172.
• Process uncertainty: Is the team using a new technology or development
approach for the first time?173.
• Resource uncertainty: Is the staff with the right skills and experience
available to work on the project?174.
Software Process Models
A process model is a "recipe" or a way of organizing the activities needed to
create a product175.
There are two competing pressures176:
1. Structure: The pressure to build a robust, high-quality product that is easy
to maintain177.
2. Speed: The pressure to get the job done as quickly and as cheaply as
possible178.
This leads to two main types of models:
• Heavyweight (Traditional) Methods:
o These are structured, step-by-step approaches where each step is
carefully defined179.
o They emphasize getting the quality right the first time180.
o They are slower and more expensive 181, often have limited customer
interaction 182, and produce a workable solution only at the final
stage183.
 • Lightweight (Agile) Methods:
o These methods emphasize speed of delivery over detailed
documentation184.
o They work with smaller teams 185, release software in increments 186,
and have very high customer interaction187. This often leads to higher
customer satisfaction188.
Common Process Models
• The Waterfall Model
o What it is: The "classical" model189. It's a simple sequence of phases:
Requirements $\rightarrow$ Design $\rightarrow$ Implementation
$\rightarrow$ Testing $\rightarrow$ Maintenance190190190190. You
must finish one phase before starting the next.
o Strengths: It's easy to manage because the phases are so rigid191. It
reinforces good habits like "define-before-design" and "design-
before-code"192.
o Weaknesses: It's unrealistic to expect users to give you all the
requirements accurately at the very beginning193. The "working
software" isn't delivered until the very end, which means serious
errors might be found too late194.
• The Spiral Model
o What it is: This model is designed to handle risk195. The project
proceeds in a spiral 196, with each loop being a new phase197.
o Each loop has 4 quadrants:
1. Determine objectives and solutions.
2. Identify and resolve risks (often by building a prototype).
3. Develop the next version of the product.
4. Review the product and plan for the next loop 198198198198.
 o Strengths: Excellent for risk management199. Software is produced
early in the lifecycle200.
o Weaknesses: Can be too complex and expensive for small projects201.
• Software Prototyping
o What it is: A prototype is a working model of one or more aspects of
the system202. It's built quickly and cheaply to test an assumption
203
and reduce risk or uncertainty204.
o Example: You're not sure if senior managers will use a complex new
information system. You build a "throwaway" prototype of the user
interface to see if they find it easy to use before you build the
expensive backend205.
o Strengths: Improves communication 206and user involvement207.
Helps clarify requirements that are only partially known208.
o Weaknesses: Users can sometimes misunderstand the prototype and
think it's the final, working system209.
• Incremental Model
o What it is: This approach breaks the system into small
components210. These components are then implemented and
delivered one by one211. Each "increment" adds more functionality212.
o Time boxing: This model often uses "time boxing," where the
deadline for an increment is rigidly fixed213. To meet the deadline,
you might have to drop some planned functionality, which is then
moved to the next increment214.
o Strengths: Users get useful software components earlier215. Feedback
from early increments improves the later ones216.
o Weaknesses: The total cost might be higher than a single-shot
approach217.
 • Agile Methods
o Why they exist: To overcome the problems of "heavyweight" models,
which are too rigid and bad at handling change218218218218.
o Key Principles: Iterative development 219219, high customer
interaction 220220220220, face-to-face communication 221, and minimal
documentation222.
o Scrum: This is a popular Agile method223.
▪ Work is divided into small time boxes called sprints (usually 2-4
weeks)224.
▪ A working increment of functionality is completed during each
sprint225.
▪ At the end of the sprint, the team and stakeholders meet to
review the increment and get feedback226226226226.
▪ Roles: Product Owner, Scrum Master, Team Member 227.
▪ Artifacts (Documents): Product Backlog, Sprint Backlog, Sprint
Burndown Chart 228.
How to Select the Right Model
• If uncertainty is high (e.g., user requirements are unclear or the customer is
unsure), use an evolutionary or agile model (like Prototyping or
Scrum)229229229229.
• If requirements are clear but the project is complex, an Incremental
approach is good230.
• If the project is large and has many high-stakes risks, the Spiral model is
appropriate231.
• If the project is simple and well-understood, the Waterfall model is fine232.
 Week 6: Software Effort Estimation
What is Estimation?
A successful project is one that is delivered on time 233, within budget 234, and with
the required functionality235. To do this, you must first estimate these targets236.
Why is Estimation So Difficult?
• Nature of software: Software is invisible and complex237.
• Political pressures: Managers might intentionally reduce an estimate just to
get a project proposal approved238238238238.
• Changing technologies: Technology changes so fast that experience from an
old project may not be applicable to a new one239.
Problems with Bad Estimates
• Over-estimating (Too much time/money):
o This will likely cause the project to take longer than it should240.
o Parkinson’s Law: "Work expands to fill the time available"241. If you
give a team 10 days for a 6-day task, they will take 10 days242.
o Brook’s Law: "Putting more people on a late job makes it later"243.
Over-estimating can lead to adding too many staff, which just
increases the amount of time spent on communication and
coordination244.
• Under-estimating (Not enough time/money):
o The biggest danger is the negative effect on quality245.
o Staff will rush to meet the pressing deadlines and produce
substandard work246.
o This bad work might not be found until the testing phase, where it
will require extensive re-work and delay the project anyway247.
 o It also destroys team motivation when targets are always
unachievable248.
The Basis for Estimation
1. Estimate Size: First, you estimate the size of the project249.
o Size is often measured in SLOC (Source Lines of Code) 250or FP
(Function Points)251.
2. Estimate Effort: Then, you use the size estimate to compute the effort252.
o Effort is often measured in person-months (pm)253. One pm is the
amount of work one person can do in one month254.
3. Calculate Cost: Finally, you calculate the cost255.
o Example: If your effort estimate is 100 pm and the average salary is
$2,000 per month, the total staff cost is $200,000 256.
Software Effort Estimation Techniques
• Bad Techniques:
o Parkinson: The "estimate" is just whatever staff effort is available257.
o Price to win: The "estimate" is just a low number that you think will
win the contract258.
• Better Techniques:
o Expert Judgment: You ask one or more knowledgeable experts for
their estimate259. This is very common when you need to change an
existing piece of software260.
o Estimation by Analogy: You find a similar completed project (a
"source case") 261and use its actual effort as the starting point for the
new "target project"262262262262. You then adjust the estimate based on
the differences263.
o Bottom-up Estimation:
 1. Break the project down into smaller and smaller component
tasks264.
2. Stop when you get to tasks small enough for one person to do
in a week or two265.
3. Estimate the cost/effort for each small task266.
4. Add all the small estimates together to get the total267.
▪ This is the best choice when a project is completely new and
you have no historical data268.
o Top-down Estimation: You start with an overall estimate for the
whole project and then break it down into the effort required for
component tasks269. Algorithmic models like FP and COCOMO are
top-down.
Top-Down Algorithmic Models
• Function Points Mark II (FP)
o What it is: A "unit of measurement" that estimates the business
functionality a system provides to a user270. It estimates size based on
functions rather than lines of code271.
o How it works: It assumes a system is made of transactions272. For
each transaction, you count the number of:
1. Input data element types (e.g., a "username" field).
2. Entity types referenced (e.g., a "User" database table).
3. Output data element types (e.g., an "error message").
o You multiply these counts by standard weights (Wi=0.58, We=1.66,
Wo=0.26) 273and add them up to get the Function Point (FP) count 274.
• COCOMO II
o What it is: The COnstructive COst MOdel275.
o The basic idea: The model uses an equation: $Effort = c * (size)^k$276.
o System Types: The constants c and k depend on the "mode" of the
project277:
▪ Organic: A small, simple project built by a small team in a
familiar environment278.
▪ Embedded: A complex project that has to run within very tight
constraints (e.g., flight control software)279.
▪ Semi-detached: A project that is a mix of the other two280.
o COCOMO II (Modern Version): The new model is more complex. It
adjusts the effort calculation using "exponent drivers" that rate the
project's qualities 281, such as:
▪ Precedentedness (PREC): How new or novel is this project? Is it
like something we've done before?282.
▪ Development Flexibility (FLEX): How many different ways are
there to meet the requirements?283.
▪ Risk Resolution (RESL): How much uncertainty is there about
the requirements?284.
▪ Team Cohesion (TEAM): Is the team small and tightly-knit or
large and dispersed?285.
▪ Process Maturity (PMAT): How structured and organized is the
company's development process?286.
 Week 7: Activity Planning
Why Plan Activities?
A detailed project plan needs more than just an effort estimate; it needs a
schedule that shows the start and completion times for every single activity287.
This detailed schedule allows you to:
• Make sure resources (like people or equipment) are available when they are
required288.
• Avoid different activities competing for the same resource at the same
time289.
• Produce a detailed plan that you can measure your actual progress
against290.
What is an "Activity"?
A project is made of many interrelated activities291. A well-defined activity:
• Must have a clearly defined start and end point292.
• Must produce a tangible deliverable (e.g., a "finished design document")293.
• Must have a duration and resource cost that you can forecast294.
• May require other activities to be completed before it can begin
(dependencies)295.
Approaches for Identifying Activities
1. Activity-Based Approach
o This involves brainstorming and creating a list of all activities the
project needs296296296296.
o A much better, more structured way to do this is by creating a Work
Breakdown Structure (WBS)297.
 o A WBS is a hierarchy: you identify the main, high-level tasks 298and
then break each one down into a set of smaller, lower-level tasks299.
o A WBS is more likely to be a complete list and helps avoid missing or
double-counting tasks300.
2. Product-Based Approach
o This approach starts by focusing on the products (deliverables), not
the activities301.
o First, you create a Product Breakdown Structure (PBS), which is a
diagram showing how the main system is broken down into all its
different products302.
o Then, you create a Product Flow Diagram (PFD), which shows which
products are needed as inputs to create other products303.
o Example: A PFD might show that "User Requirements" (a product)
flows into "Overall System Specification" (another product)304.
o This PFD can then be easily turned into an activity list305.
3. Hybrid Approach
o This is the most commonly used approach306.
o It's a mix of the other two307. The WBS is created by listing the final
deliverables (from the product-based approach) 308and then listing
the set of activities required to produce each of them (from the
activity-based approach)309.
Creating a Project Schedule
There are four main steps to create the final schedule:
• Step 1: Create an "Ideal" Plan
o First, you identify all the activities and the order they need to be
done in310.
 o You use this to create an "ideal activity plan," which assumes you
have no constraints on resources (e.g., unlimited money and
people)311.
• Step 2: Analyze Activity Risks
o You analyze the ideal plan for potential problems312. This might force
you to alter the plan313.
• Step 3: Allocate Resources
o Now you apply real-world constraints314. You allocate your available
resources to the activities315.
o Example: Your ideal plan might have "Code Module A" and "Code
Module B" happening at the same time. But if you only have one
developer, you have to change the plan to make them happen one
after the other.
• Step 4: Produce and Publish the Schedule
o You now have your final, realistic project schedule 316, which shows
the start date 317, end date 318, and resource requirements 319 for
every activity.
Network Planning Models
These are techniques used to visually model the project's activities and their
relationships320.
• Critical Path Method (CPM): This is the most common technique321.
• How it works: It represents activities as nodes (boxes) and their
dependencies as links (arrows)322.
• Key Rules:
o A project network should have only one start node and one end
node323.
o A node (activity) has a duration (e.g., "5 days")324.
o A link (arrow) has no duration; it just shows a dependency325.
o Precedents are the activities that must be finished immediately
before another activity can begin326.