SPM IMP QUESTIONS *Unit :Activity Planning & Network Modeling* - Enlist and explain the four activity-relationship

types (Start-to-Start, Finish-to-Start, etc.) with neat diagrams.

Activity-Relationship Types in Network Modeling (SPM)

INTRODUCTION

In Activity Planning and Network Modeling, activity relationships (dependencies) define the logical order in which
project activities are executed. They specify start and finish constraints between activities and are essential for
PERT/CPM scheduling.

MAIN ANSWER

There are four standard activity-relationship types:

1) Finish-to-Start (FS)

• Definition: A successor activity cannot start until its predecessor finishes.

• Most commonly used dependency in software projects.

• Used when output of first activity is required to begin the next.

Diagram (FS)

[ Activity A ] -----> [ Activity B ]

Finish Start

Example:
Coding must finish before Testing starts.

2) Start-to-Start (SS)

• Definition: A successor activity cannot start until the predecessor starts.

• Activities may then proceed in parallel.

• Used to overlap tasks to reduce project duration.

Diagram (SS)

[ Activity A ]

[ Activity B ]

(Start together)

Example:
Test case design can start once coding starts.

3) Finish-to-Finish (FF)
 • Definition: A successor activity cannot finish until the predecessor finishes.

• Ensures simultaneous completion or controlled ending.

Diagram (FF)

[ Activity A ] ----->|

|----> Finish together

[ Activity B ] ----->|

Example:
Documentation review cannot finish until development finishes.

4) Start-to-Finish (SF)

• Definition: A successor activity cannot finish until the predecessor starts.

• Rarely used and conceptually complex.

• Mainly used in shift-based or system takeover scenarios.

Diagram (SF)

[ Activity A ] (Start)

[ Activity B ] (Finish)

Example:
Old system support ends only after new system operation starts.

SUMMARY TABLE

Dependency Type Meaning

Finish-to-Start (FS) Successor starts after predecessor finishes

Start-to-Start (SS) Successor starts after predecessor starts

Finish-to-Finish (FF) Successor finishes after predecessor finishes

Start-to-Finish (SF) Successor finishes after predecessor starts

CONCLUSION

Activity-relationship types define execution logic in network models, enabling accurate project scheduling,
dependency control, and critical path analysis in Software Project Management.
If you want, I can next give numericals on network modeling, PERT vs CPM, or critical path PYQs exactly as asked in
SPPU exams.

- Explain the rules for formulating a network model, illustrating with a diagram.

Rules for Formulating a Network Model (SPM – Activity Planning & Network Modeling)

INTRODUCTION

A network model represents a project as a set of activities and events arranged according to their logical
dependencies. Correct formulation of the network is essential for PERT/CPM analysis, scheduling, and identification
of the critical path.

MAIN ANSWER

Rules for formulating a network model:

1. Each activity must have a unique start event and end event

o Activities are represented by arrows (in AOA) or nodes (in AON).

o No two activities should share the same identification.

2. Events should be numbered uniquely and sequentially

o Event numbers must be unique.

o Numbering should proceed from left to right following project flow.

3. No activity can start until all its predecessor activities are completed

o Logical dependencies must be strictly maintained.

o Parallel activities are allowed only when logically independent.

4. The network must have only one start event and one end event

o Start event: No predecessor activities.

o End event: No successor activities.

5. Loops are not permitted in a network

o Circular dependencies (A depends on B and B depends on A) are invalid.

o Network must be acyclic.

6. Dummy activities should be used only when necessary

o Dummy activities represent logical dependency only.

o They consume zero time and resources.

o Used to avoid ambiguity and maintain correct precedence.

7. All activities must be connected

o Isolated activities are not allowed.

o Every activity must lie on a path between start and end events.

8. Network logic should be simple and clearly understandable

o Avoid unnecessary complexity.

o Ensure easy identification of critical and non-critical paths.

DIAGRAM: Sample Network Model (AOA)

Start
|
(1)
|
[A]
|
(2)
/ \
[B] [C]
| |
(3) (4)
\ /
[D]
|
(5)
|
End
Explanation:

• Activity A starts the project.

• B and C run in parallel after A.

• D starts only after both B and C are completed.

• Project ends after D.

CONCLUSION

Proper formulation of a network model ensures correct scheduling, dependency control, and critical path
identification, forming the foundation of effective Software Project Management.

- Differentiate Forward Pass from Backward Pass(2 column only!) and state the significance of each.

Forward Pass vs Backward Pass in Network Scheduling (SPM)

INTRODUCTION

In PERT/CPM network analysis, Forward Pass and Backward Pass are systematic procedures used to determine time
parameters of activities and identify the critical path of a project.

DIFFERENTIATION (2-Column Only)

Forward Pass Backward Pass

Calculates Earliest Start Time (ES) and Earliest Finish Calculates Latest Start Time (LS) and Latest Finish Time
Time (EF) (LF)

Network is traversed from start event to end event Network is traversed from end event to start event

Assumes activities start as early as possible Assumes activities finish as late as possible

EF = ES + Activity Duration LS = LF − Activity Duration

Used to find allowable delays without affecting project

Used to find minimum project completion time
duration

SIGNIFICANCE

Significance of Forward Pass

• Determines earliest possible project completion time

• Identifies early start and finish schedules

• Helps in initial project planning and scheduling

Significance of Backward Pass

• Determines latest allowable times for activities

• Helps in identifying slack/float

• Essential for critical path identification and delay control

CONCLUSION

Forward Pass defines the fastest execution plan, while Backward Pass identifies scheduling flexibility. Together,
they enable accurate critical path analysis and effective project control in Software Project Management.

- Define Critical Path, how to identify it, its limitations and possible remedies.

Critical Path in Software Project Management (SPM)

INTRODUCTION

The Critical Path is the longest-duration path in a project network from start to finish, determining the minimum
project completion time. Any delay in critical path activities directly delays the entire project.

MAIN ANSWER

Definition

• Critical Path is the sequence of activities with zero float (slack).

• It represents the maximum total duration among all possible paths in the network.
How to Identify the Critical Path

1. Construct the network diagram (PERT/CPM).

2. Perform Forward Pass to calculate ES and EF of all activities.

3. Perform Backward Pass to calculate LS and LF of all activities.

4. Calculate Float (Slack) for each activity:

o Float = LS − ES = LF − EF

5. Identify activities with zero float.

6. The continuous path formed by zero-float activities is the Critical Path.

DIAGRAM: Critical Path Illustration

Start

[A] (5)

[B] (4)

[C] (6)

End

Critical Path: A → B → C
Project Duration = 5 + 4 + 6 = 15 units

Limitations of Critical Path

1. Ignores resource constraints such as limited manpower or tools.

2. Assumes fixed activity durations, which may not be realistic.

3. Does not consider uncertainty and risk explicitly.

4. Becomes complex for very large projects with frequent changes.

5. Focuses only on one path, neglecting near-critical paths.

Possible Remedies

1. Resource leveling to address resource limitations.

2. Use PERT analysis to handle uncertainty in activity durations.

3. Continuous monitoring of near-critical paths.

 4. Crashing activities by adding resources to reduce duration.

5. Regular network updating and re-planning during execution.

EXAMPLE

In a software development project, if activities like requirement analysis → coding → testing have zero float, they
form the critical path. Delay in testing will delay product delivery, regardless of other activities finishing early.

CONCLUSION

The Critical Path determines project duration and control focus. Although it has limitations, applying PERT, resource
management, and continuous monitoring makes it an effective tool for successful software project scheduling and
control.

List and detail the objectives and steps of Activity Planning.

Activity Planning – Objectives and Steps (SPM)

INTRODUCTION

Activity Planning is the process of identifying, sequencing, and scheduling project activities to ensure systematic
execution of a software project within time, cost, and resource constraints.

OBJECTIVES OF ACTIVITY PLANNING

1. Identify all project activities

o Break the project into manageable and measurable tasks.

2. Establish logical dependencies

o Define precedence relationships among activities.

3. Estimate project duration

o Determine time required for each activity and the overall project.

4. Optimize resource utilization

o Ensure efficient allocation of manpower and other resources.

5. Enable effective scheduling and control

o Provide a basis for monitoring progress and taking corrective actions.

6. Identify critical activities

o Help in locating the critical path and zero-float activities.

7. Reduce project risks and uncertainties

o Anticipate bottlenecks and plan preventive measures.

STEPS OF ACTIVITY PLANNING

1. Project Decomposition
 o Divide the project into smaller activities using Work Breakdown Structure (WBS).

2. Activity Identification

o List all activities required to complete each deliverable.

3. Activity Sequencing

o Determine precedence and dependency relationships between activities.

4. Activity Duration Estimation

o Estimate time for each activity using expert judgment, historical data, or models.

5. Network Construction

o Develop PERT/CPM network diagram showing activity flow.

6. Schedule Development

o Apply forward pass and backward pass to compute time parameters.

7. Critical Path Identification

o Identify zero-float activities forming the critical path.

8. Schedule Review and Optimization

o Adjust schedule using resource leveling or crashing, if required.

EXAMPLE

In a software development project, activities such as requirement analysis, design, coding, testing, and deployment
are identified, sequenced, timed, and scheduled to ensure timely project completion.

CONCLUSION

Activity Planning provides a structured roadmap for project execution, enabling accurate scheduling, effective
control, and successful completion of software projects.

- Define Scheduling and describe its types and benefits.

Scheduling in Software Project Management (SPM)

INTRODUCTION

Scheduling is the process of allocating time and resources to project activities and arranging them in a logical
sequence to ensure timely and systematic project completion.

DEFINITION

• Scheduling is the activity of deciding start and finish times of project activities based on precedence
constraints, resource availability, and project deadlines.

TYPES OF SCHEDULING

1. Time-based Scheduling

o Focuses on activity durations and sequence.

o Uses tools like Gantt charts and PERT/CPM networks.

 o Objective is to meet project deadlines.

2. Resource-based Scheduling

o Considers availability and limitations of resources.

o Activities are scheduled to avoid resource conflicts.

o Often involves resource leveling.

3. Forward Scheduling

o Activities are scheduled as early as possible.

o Uses Forward Pass calculations.

o Helps determine earliest project completion time.

4. Backward Scheduling

o Activities are scheduled as late as possible without delaying the project.

o Uses Backward Pass calculations.

o Useful when delivery date is fixed.

5. Milestone-based Scheduling

o Project is divided into key milestones.

o Progress is tracked at significant checkpoints.

BENEFITS OF SCHEDULING

1. Ensures timely project completion

o Prevents delays by defining clear timelines.

2. Improves resource utilization

o Avoids overloading or underutilization of resources.

3. Facilitates monitoring and control

o Enables comparison of planned vs actual progress.

4. Identifies critical activities

o Helps in detecting critical path and zero-float tasks.

5. Enhances coordination and communication

o Provides a common reference schedule for the team.

6. Supports decision making

o Helps in re-planning, crashing, and risk mitigation.

EXAMPLE

In a software project, scheduling defines when requirements analysis, design, coding, testing, and deployment
should start and finish, ensuring delivery on the committed date.
CONCLUSION

Scheduling transforms project plans into executable timelines, enabling effective control, optimal resource usage,
and successful completion of software projects within constraints.

*Unit : Project Monitoring & Control* - Explain Earned Value Analysis; define PV, AC, EV, CV, SV, CPI, SPI (often asked
as a numerical).

Earned Value Analysis (EVA) – Project Monitoring & Control (SPM)

INTRODUCTION

Earned Value Analysis (EVA) is a quantitative project performance measurement technique that integrates scope,
time, and cost to assess schedule and cost performance of a project at any given time.

MAIN ANSWER

Definition

• Earned Value Analysis compares planned work, completed work, and actual cost incurred to determine
project performance and progress.

EVA PARAMETERS (WITH DEFINITIONS & FORMULAE)

1. Planned Value (PV)

o Definition: Budgeted cost of work scheduled to be completed till a given time.

o Formula:
PV = Budgeted cost of planned work

2. Actual Cost (AC)

o Definition: Actual cost incurred for work completed till date.

o Formula:
AC = Actual expenditure on completed work

3. Earned Value (EV)

o Definition: Budgeted cost of actual work completed till date.

o Formula:
EV = Budgeted cost × % of work completed

4. Cost Variance (CV)

 o Definition: Difference between earned value and actual cost.

o Formula:
CV = EV − AC

o Interpretation:

▪ CV > 0 → Under budget

▪ CV < 0 → Over budget

5. Schedule Variance (SV)

o Definition: Difference between earned value and planned value.

o Formula:
SV = EV − PV

o Interpretation:

▪ SV > 0 → Ahead of schedule

▪ SV < 0 → Behind schedule

6. Cost Performance Index (CPI)

o Definition: Cost efficiency of project work.

o Formula:
CPI = EV / AC

o Interpretation:

▪ CPI > 1 → Cost efficient

▪ CPI < 1 → Cost overrun

7. Schedule Performance Index (SPI)

o Definition: Schedule efficiency of project work.

o Formula:
SPI = EV / PV

o Interpretation:

▪ SPI > 1 → Ahead of schedule

▪ SPI < 1 → Behind schedule

EXAMPLE (NUMERICAL – TYPICAL EXAM STYLE)

Given:

• PV = ₹50,000

• AC = ₹55,000

• EV = ₹45,000
Calculations:

• CV = 45,000 − 55,000 = −10,000 (Over budget)

• SV = 45,000 − 50,000 = −5,000 (Behind schedule)

• CPI = 45,000 / 55,000 = 0.82

• SPI = 45,000 / 50,000 = 0.90

CONCLUSION

Earned Value Analysis provides an objective and integrated view of project performance, enabling early detection
of cost overruns and schedule delays, and is a powerful tool for effective project monitoring and control in Software
Project Management.

Outline the steps in a Change-Control Procedure and draw its block diagram.

Change-Control Procedure (SPM – Project Monitoring & Control)

INTRODUCTION

Change-Control Procedure is a formal, systematic process used to identify, evaluate, approve/reject, and
implement changes in project scope, schedule, cost, or quality while maintaining project integrity.

STEPS IN CHANGE-CONTROL PROCEDURE

1. Change Request Identification

o Change is formally identified and documented by stakeholder/user.

o Change Request Form (CRF) is prepared.

2. Change Logging and Registration

o Request is recorded in change log for traceability.

o Assigns unique change ID.

3. Impact Analysis

o Analyze impact on scope, cost, schedule, resources, and risk.

o Technical and managerial feasibility is assessed.

4. Change Evaluation

o Change is reviewed by Change Control Board (CCB).

o Benefits are weighed against risks and costs.

5. Approval or Rejection

o CCB approves, defers, or rejects the change request.

o Decision is formally documented.

6. Change Implementation

o Approved change is implemented in project plan, design, or code.

 o Baselines are updated accordingly.

7. Verification and Validation

o Ensure change is correctly implemented and tested.

o No adverse impact on existing functionality.

8. Change Closure

o Change request is closed after successful implementation.

o Documentation is updated.

BLOCK DIAGRAM: CHANGE-CONTROL PROCEDURE

[ Change Request Raised ]

[ Change Logging & Registration ]

[ Impact Analysis ]

[ Change Evaluation (CCB) ]

-------------------

| |

v v

[ Approved ] [ Rejected ]

| |

v v

[ Implement Change ] [ Close Request ]

[ Verify & Validate ]

[ Update Baseline & Close ]

EXAMPLE

In a software project, a client requests a new reporting feature after design completion. The request undergoes
impact analysis, is approved by CCB, implemented, tested, and then formally closed.

CONCLUSION

A well-defined Change-Control Procedure prevents uncontrolled scope creep, ensures accountability, and maintains
cost, schedule, and quality discipline in software projects.

List and explain methods/tools for visualizing project progress (Gantt, Charts, Slip Charts, etc.).

Methods / Tools for Visualizing Project Progress (SPM – Project Monitoring & Control)

INTRODUCTION

Project progress visualization tools provide a graphical representation of planned vs actual progress, enabling
managers to monitor status, detect delays, and take corrective actions effectively.

MAIN ANSWER

1) Gantt Chart

• A time-based bar chart showing activities against a time scale.

• Displays planned start–finish, actual progress, and overlaps.

• Useful for tracking individual activities.

Diagram (Gantt Chart)

Activity A |████████

Activity B | ███████

Activity C | █████

----------------> Time

Use: Monitoring schedule progress and coordination.

2) Milestone Chart

• Represents key events or checkpoints rather than activities.

• Shows completion status of important deliverables.

Diagram (Milestone Chart)

Start ---- M1 ---- M2 ---- M3 ---- End

Use: Management-level progress reporting.

3) Slip Chart
 • Shows difference between planned and actual completion dates of milestones.

• Highlights schedule slippage trends over time.

Diagram (Slip Chart)

Milestone

M1 | Planned ---- Actual

M2 | Planned -------- Actual

Use: Identifying delays and schedule deviation.

4) Tracking Gantt Chart

• An enhanced Gantt chart comparing baseline schedule vs current progress.

• Highlights behind/ahead schedule activities.

Use: Detecting deviations from original plan.

5) S-Curve (Progress Curve)

• Graph of cumulative effort or cost vs time.

• Planned and actual curves are compared.

Diagram (S-Curve)

Cost

| Actual

| /

| / Planned

|___/____________ Time

Use: Monitoring cost and effort trends.

6) Earned Value Graphs

• Graphical representation of PV, EV, and AC over time.

• Visually indicates cost and schedule performance.

Use: Performance analysis and forecasting.

SUMMARY TABLE

Tool Purpose

Gantt Chart Activity-wise schedule tracking

Milestone Chart Monitoring key deliverables

Tool Purpose

Slip Chart Identifying schedule slippage

Tracking Gantt Planned vs actual comparison

S-Curve Cost/effort trend analysis

EVA Graphs Cost and schedule performance

CONCLUSION

Visualization tools convert project data into actionable insights, enabling timely detection of delays, better
communication, and effective project monitoring and control in Software Project Management.

- List and explain the different types of Project Status Reports.

Project Status Reports (SPM – Project Monitoring & Control)

INTRODUCTION

Project Status Reports are formal documents used to communicate the current state of a project with respect to
schedule, cost, scope, quality, and risks to stakeholders and management.

MAIN ANSWER

1) Progress Report

• Reports work completed during a specific period.

• Compares planned progress vs actual progress.

• Highlights completed tasks, ongoing tasks, and pending work.

Purpose: To track day-to-day or week-to-week project advancement.

2) Schedule Status Report

• Focuses on time-related performance.

• Identifies ahead/behind schedule activities.

• Often derived from Gantt charts, milestone charts, or slip charts.

Purpose: To monitor schedule adherence and delays.

3) Cost Status Report

• Reports budgeted cost, actual cost, and cost variance.

• Uses Earned Value parameters (AC, EV, CV, CPI).

Purpose: To control project expenditure and detect cost overruns.

4) Milestone Status Report

• Tracks achievement of predefined milestones.

• Indicates milestones as achieved, pending, or delayed.

Purpose: To provide high-level management visibility.

5) Risk Status Report

• Lists identified risks, their probability and impact.

• Reports new risks, risk mitigation actions, and residual risks.

Purpose: To ensure proactive risk monitoring and mitigation.

6) Quality Status Report

• Reports quality metrics, defects, and rework status.

• Includes results of reviews, audits, and testing activities.

Purpose: To ensure product and process quality compliance.

7) Exception Status Report

• Generated only when deviations exceed acceptable limits.

• Highlights critical issues requiring immediate management attention.

Purpose: To enable quick corrective actions.

SUMMARY TABLE

Report Type Focus Area

Progress Report Work completion status

Schedule Status Report Time and delays

Cost Status Report Budget and cost variance

Milestone Status Report Key deliverables

Risk Status Report Project risks

Quality Status Report Defects and standards

Exception Report Major deviations

CONCLUSION

Project Status Reports ensure transparency, control, and informed decision-making, enabling managers to detect
issues early and maintain project alignment with objectives in Software Project Management.

- Write a short note on Cost Monitoring and its approaches.

Cost Monitoring and its Approaches (SPM – Project Monitoring & Control)

INTRODUCTION

Cost Monitoring is the continuous process of tracking, reviewing, and controlling project expenditure to ensure that
the project is completed within the approved budget and financial deviations are detected early.

MAIN ANSWER

Cost Monitoring

• Involves comparison of actual cost with planned/budgeted cost at regular intervals.

• Helps in identifying cost overruns, underutilization, and inefficiencies.

• Forms a basis for corrective and preventive actions.

APPROACHES TO COST MONITORING

1) Budgetary Control Approach

• Project budget is divided into cost heads or phases.

• Actual expenditure is periodically compared with allocated budget.

• Variances are analyzed and corrective action is taken.

Use: Simple and traditional cost control.

2) Earned Value Analysis (EVA)

• Integrates cost, schedule, and scope.

• Uses parameters such as PV, EV, AC, CV, CPI.

• Provides quantitative measure of cost performance.

Use: Most effective and widely used method.

3) Milestone-based Cost Monitoring

• Costs are monitored at predefined milestones.

• Each milestone has an allocated budget.

• Suitable for management-level review.

Use: High-level cost tracking.

4) Activity-based Cost Monitoring

• Cost is tracked activity-wise instead of phase-wise.

• Helps in identifying cost-intensive activities.

Use: Detailed operational control.

5) Trend Analysis

• Analyzes cost trends over time using graphs or S-curves.

• Predicts future cost overruns based on past data.

Use: Forecasting and early warning.

EXAMPLE

In a software development project, if coding costs exceed budget, EVA can detect a negative CV and CPI < 1,
prompting corrective measures such as resource reallocation or scope adjustment.

CONCLUSION

Cost Monitoring ensures financial discipline in software projects. By applying methods like EVA, budgetary control,
and trend analysis, managers can detect deviations early and keep the project within budget.
*Unit : Contract Management* - Explain the stages in Contract Placement.

Stages in Contract Placement (SPM – Contract Management)

INTRODUCTION

Contract Placement is the formal process of selecting a vendor/contractor and awarding a contract for software
development or related services, ensuring technical, financial, and legal compliance.

MAIN ANSWER

1) Requirement Identification

• Client clearly defines scope of work, deliverables, constraints, and expectations.

• Forms the basis for contract preparation.

2) Preparation of Tender / RFP

• Tender document / Request for Proposal (RFP) is prepared.

• Includes technical requirements, schedule, cost structure, quality standards, and legal terms.

3) Invitation to Tender

• Tenders are advertised or sent to eligible vendors.

• Ensures competitive bidding and transparency.

4) Vendor Response Submission

• Vendors submit technical and financial proposals within stipulated time.

• Proposals must comply with tender conditions.

5) Technical Evaluation

• Proposals are evaluated based on technical capability, experience, methodology, and resources.

• Non-compliant bids are rejected.

6) Financial Evaluation

• Financial bids of technically qualified vendors are analyzed.

• Comparison based on cost, payment terms, and value for money.

7) Vendor Negotiation

• Negotiation on price, delivery schedule, scope clarification, penalties, and responsibilities.

• Aims to reach mutually acceptable terms.

8) Contract Award

• Final selection of vendor.

• Letter of Intent (LoI) or Work Order is issued.

9) Contract Signing

• Formal legal agreement is signed by both parties.

• Contract becomes legally binding.

EXAMPLE

In a government software project, an RFP is released, vendors submit bids, technical and financial evaluations are
done, negotiations held, and finally a fixed-price contract is awarded to the selected vendor.

CONCLUSION

Contract placement ensures systematic vendor selection and legal clarity, minimizing risks and ensuring successful
execution of software projects through well-defined responsibilities and obligations.

- Define Contract Management and list typical contract terms.

Contract Management and Typical Contract Terms (SPM – Contract Management)

INTRODUCTION

Contract Management is the systematic process of planning, drafting, executing, monitoring, and closing contracts
to ensure that project objectives are met while complying with legal, technical, and financial obligations.

DEFINITION

• Contract Management involves controlling and administering a contract throughout its life cycle to ensure
that both client and contractor fulfill their responsibilities in terms of scope, cost, schedule, and quality.

TYPICAL CONTRACT TERMS

1. Scope of Work

o Clearly defines services, deliverables, and boundaries of the project.

2. Contract Price and Payment Terms

o Specifies total cost, payment milestones, mode of payment, and currency.

3. Schedule and Delivery Milestones

o Defines project timelines, deadlines, and intermediate milestones.

4. Roles and Responsibilities

o Clearly assigns obligations of client and contractor.

 5. Change Control Clause

o Procedure for handling scope or requirement changes and their impact.

6. Quality and Acceptance Criteria

o Standards, metrics, and conditions for acceptance of deliverables.

7. Penalty and Incentive Clauses

o Penalties for delay or non-compliance and incentives for early completion.

8. Confidentiality and Intellectual Property Rights

o Ownership of source code, documents, and data confidentiality.

9. Risk and Liability Clause

o Allocation of project risks, liabilities, and insurance requirements.

10. Termination Clause

o Conditions under which contract may be terminated by either party.

11. Dispute Resolution Clause

o Methods such as arbitration, mediation, or legal jurisdiction.

12. Force Majeure Clause

o Protection against uncontrollable events like natural disasters.

EXAMPLE

In a software development contract, terms clearly specify fixed price, milestone-based payments, IP ownership of
code, penalties for delay, and formal change-control procedures.

CONCLUSION

Effective contract management ensures legal clarity, risk control, and smooth project execution. Well-defined
contract terms protect the interests of both parties and contribute to successful software project delivery.

- Describe the layers of the Software Configuration Management (SCM) process.

Layers of Software Configuration Management (SCM) Process (SPM)

INTRODUCTION

Software Configuration Management (SCM) is a disciplined process used to identify, organize, control, and track
changes in software artifacts throughout the software life cycle, ensuring integrity and traceability.

MAIN ANSWER

The SCM process is commonly organized into the following layers (functional components):

1) Configuration Identification
 • Identifies configuration items (CIs) such as source code, design documents, test cases, manuals.

• Establishes baselines at defined project milestones.

• Each CI is assigned a unique identifier.

Purpose: To know what is being controlled.

2) Configuration Control

• Manages changes to configuration items after baseline is established.

• Uses Change Control Procedure and Change Control Board (CCB).

• Ensures only authorized changes are implemented.

Purpose: To prevent uncontrolled changes (scope creep).

3) Configuration Status Accounting

• Records and reports the status of configuration items and changes.

• Maintains information such as current version, change history, approval status.

Purpose: To provide visibility and traceability of configurations.

4) Configuration Audit and Review

• Verifies that configuration items conform to specifications.

• Includes functional audits and physical audits.

• Ensures approved changes are correctly implemented.

Purpose: To ensure consistency, correctness, and compliance.

5) Version Control (Release Management)

• Manages multiple versions and variants of software products.

• Controls check-in, check-out, branching, and merging.

• Supports parallel development and maintenance.

Purpose: To maintain product evolution and stability.

DIAGRAM: LAYERS OF SCM PROCESS

+-------------------------------+

| Configuration Identification |

+-------------------------------+

+-------------------------------+
| Configuration Control |

+-------------------------------+

+-------------------------------+

| Status Accounting |

+-------------------------------+

+-------------------------------+

| Configuration Audit & Review |

+-------------------------------+

+-------------------------------+

| Version / Release Control |

+-------------------------------+

EXAMPLE

In a software development project, source code and documents are identified as CIs, baselined after design, changes
are approved by CCB, versions are tracked using tools like Git, and audits ensure correct implementation.

CONCLUSION

The layers of SCM provide structured change control, traceability, and quality assurance, ensuring that software
products evolve in a controlled, consistent, and reliable manner throughout the project life cycle.

*Unit : Agile Project Management* - Differentiate Predictive (Waterfall) and Empirical (Agile) management
approaches.

Predictive (Waterfall) vs Empirical (Agile) Management Approaches (SPM – Agile Project Management)

INTRODUCTION

Project management approaches can be broadly classified into Predictive (plan-driven) and Empirical (Agile). They
differ in how planning, execution, control, and change handling are performed during software development.

DIFFERENTIATION (2-COLUMN ONLY)

Predictive (Waterfall) Management Empirical (Agile) Management

Based on detailed upfront planning Based on continuous learning and adaptation

Requirements are fixed early Requirements evolve throughout development

Progress measured by phase completion Progress measured by working software

Predictive (Waterfall) Management Empirical (Agile) Management

Change is costly and discouraged Change is welcomed and expected

Linear, sequential lifecycle Iterative and incremental lifecycle

Heavy documentation driven Lightweight documentation

Customer involvement is limited Continuous customer collaboration

Risks discovered late in the project Risks addressed early and continuously

Best suited for stable, well-defined projects Best suited for dynamic, uncertain projects

SIGNIFICANCE / USAGE CONTEXT

Predictive (Waterfall)

• Suitable for regulatory, fixed-scope projects

• Emphasizes control, predictability, and documentation

Empirical (Agile)

• Suitable for fast-changing software environments

• Emphasizes flexibility, feedback, and rapid value delivery

CONCLUSION

Predictive management relies on upfront certainty and strict planning, whereas Empirical (Agile) management
relies on inspection, adaptation, and frequent feedback. The choice depends on requirement stability, risk level,
and customer involvement.

- Explain the Scrum framework: roles (Scrum Master, Product Owner, Team), ceremonies, and artifacts.

Scrum Framework – Roles, Ceremonies, and Artifacts (SPM – Agile Project Management)

INTRODUCTION

Scrum is an Agile framework based on empirical process control that uses iteration, inspection, and adaptation to
deliver high-quality software in short, time-boxed iterations called Sprints.

1) ROLES IN SCRUM

1.1 Product Owner

• Represents the customer and stakeholders.

• Responsible for maximizing product value.

• Creates, prioritizes, and maintains the Product Backlog.

• Decides what to build next.

1.2 Scrum Master

• Acts as a facilitator and servant leader.

• Ensures Scrum is understood and followed.

• Removes impediments faced by the team.

• Protects the team from external interruptions.

1.3 Development Team

• Cross-functional and self-organizing group.

• Responsible for designing, developing, testing, and delivering the product increment.

• Typically 5–9 members.

• Decides how to do the work.

2) SCRUM CEREMONIES (EVENTS)

2.1 Sprint

• Fixed-length iteration (usually 2–4 weeks).

• Produces a potentially shippable product increment.

2.2 Sprint Planning

• Conducted at the start of the Sprint.

• Team selects items from Product Backlog.

• Defines Sprint Goal and creates Sprint Backlog.

2.3 Daily Scrum (Daily Stand-up)

• 15-minute daily meeting.

• Team members answer:

o What did I do yesterday?

o What will I do today?

o What obstacles do I face?

2.4 Sprint Review

• Held at end of Sprint.

• Team demonstrates working software to stakeholders.

• Feedback is collected for backlog refinement.

2.5 Sprint Retrospective

• Focuses on process improvement.

• Team reflects on what went well and what to improve.

• Action items are identified for next Sprint.

3) SCRUM ARTIFACTS

3.1 Product Backlog

• Ordered list of all desired product features.

• Owned and prioritized by Product Owner.

• Continuously refined.

3.2 Sprint Backlog

• Subset of Product Backlog selected for the Sprint.

• Includes tasks and Sprint Goal.

• Owned by the Development Team.

3.3 Increment

• Sum of all completed backlog items in a Sprint.

• Must meet Definition of Done.

• Represents working, potentially releasable software.

SUMMARY TABLE

Roles

• Product Owner → What to build

• Scrum Master → How Scrum works

• Development Team → Build the product

Ceremonies

• Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective

Artifacts

• Product Backlog, Sprint Backlog, Increment

CONCLUSION

The Scrum framework provides clear roles, structured ceremonies, and transparent artifacts, enabling frequent
delivery, adaptability, and continuous improvement, making it highly effective for modern software project
management.
- Demonstrate the three stages of Agile projects with examples.

Three Stages of Agile Projects (SPM – Agile Project Management)

INTRODUCTION

Agile projects evolve through iterative and incremental stages where planning, development, and delivery are
performed continuously with feedback. Broadly, an Agile project progresses through three major stages.

1) Initiation (Concept / Inception) Stage

Explanation

• Defines the product vision and business objective.

• High-level requirements are identified as user stories.

• Feasibility, risks, and initial scope are assessed.

• Agile team and stakeholders are identified.

Key Activities

• Product vision definition

• Initial Product Backlog creation

• Rough effort and cost estimation

Example
For an online food delivery app, features like user registration, restaurant listing, order placement are identified at a
high level.

2) Iteration (Development) Stage

Explanation

• Core stage where the product is developed incrementally.

• Work is divided into Sprints.

• Each Sprint delivers a working increment of software.

• Continuous testing, review, and feedback are performed.

Key Activities

• Sprint Planning

• Design, coding, and testing

• Sprint Review and Retrospective

Example
In each Sprint of the food delivery app:

• Sprint 1: User login and profile

• Sprint 2: Restaurant search and menu display

• Sprint 3: Order placement and payment

3) Release (Delivery & Maintenance) Stage

Explanation

• Completed increments are released to users.

• Product is deployed and monitored.

• Feedback leads to enhancements or bug fixes.

• Maintenance and support are provided.

Key Activities

• Final testing and deployment

• User training and documentation

• Performance monitoring and updates

Example
The food delivery app is released on Play Store/App Store, user feedback is collected, and updates like discount
coupons or live tracking are added.

SUMMARY TABLE

Stage Focus

Initiation Vision, scope, feasibility

Iteration Incremental development

Release Delivery and improvement

CONCLUSION

Agile projects progress through Initiation, Iteration, and Release stages, enabling early value delivery, adaptability
to change, and continuous improvement, which makes Agile highly suitable for dynamic software environments.

- Explain two Agile estimation methods (e.g., Planning Poker, T-Shirt sizing).

Agile Estimation Methods (SPM – Agile Project Management)

INTRODUCTION

Agile estimation is used to approximate effort and complexity of user stories in a relative, collaborative manner,
rather than predicting exact time or cost upfront.

1) Planning Poker

Explanation

• A consensus-based estimation technique used by Agile teams.

• Each team member estimates effort using numbered cards (commonly Fibonacci series: 1, 2, 3, 5, 8, 13…).
 • Estimates are revealed simultaneously to avoid bias.

• Differences are discussed and re-estimated until consensus is reached.

Steps

1. Product Owner explains the user story.

2. Team discusses assumptions and complexity.

3. Each member selects a planning poker card.

4. Cards are revealed together.

5. Discussion and re-voting until agreement.

Example
Estimating a user story: “As a user, I want password reset via email.”
After discussion, team agrees on 5 story points.

Advantages

• Encourages team participation

• Reduces dominance and bias

• Improves estimation accuracy through discussion

2) T-Shirt Sizing

Explanation

• A high-level, relative estimation method using size categories instead of numbers.

• Sizes typically include: XS, S, M, L, XL.

• Used in early project stages when details are limited.

Steps

1. User stories are reviewed briefly.

2. Team assigns a relative size based on complexity and effort.

3. Stories are later refined into detailed estimates if required.

Example

• Login feature → S

• Payment gateway integration → L

• Recommendation engine → XL

Advantages

• Fast and simple

• Useful when requirements are unclear or evolving

• Easy for non-technical stakeholders to understand

COMPARATIVE SUMMARY
Planning Poker T-Shirt Sizing

Uses story points Uses size labels

Detailed estimation High-level estimation

Suitable for Sprint planning Suitable for early backlog grooming

Requires more discussion Quick and lightweight

CONCLUSION

Planning Poker provides accurate, consensus-driven estimates, while T-Shirt sizing offers quick, high-level
approximation. Both methods support Agile’s goal of flexible and adaptive planning.

- Define Product Backlog and illustrate with a diagram.

Product Backlog (Agile Project Management – Scrum)

INTRODUCTION

The Product Backlog is an ordered, evolving list of all work required for a product. It is the single source of
requirements and is continuously refined to maximize product value.

DEFINITION

• Product Backlog is a prioritized list of user stories, features, enhancements, bug fixes, and technical tasks,
maintained and owned by the Product Owner.

MAIN ANSWER (KEY CHARACTERISTICS)

1. Single Source of Requirements

o Contains everything needed to build and improve the product.

2. Prioritized by Value

o Items are ordered based on business value, risk, urgency, and dependencies.

3. Dynamic and Evolving

o Continuously updated, refined, added, or re-prioritized.

4. Expressed as User Stories

o Commonly written in “As a user, I want…, so that…” format.

5. Estimated Items

o Each item is assigned relative effort estimates (story points / sizes).

6. Owned by Product Owner

o Product Owner is responsible for content, ordering, and clarity.

7. Input to Sprint Planning

 o Top-priority items are selected to form the Sprint Backlog.

DIAGRAM: PRODUCT BACKLOG STRUCTURE

+-------------------------------+

| PRODUCT BACKLOG |

+-------------------------------+

| Priority ↑ |

| |

| 1. User Login (High) |

| 2. User Registration |

| 3. Search Functionality |

| 4. Payment Integration |

| 5. Order History |

| 6. UI Enhancements |

| 7. Performance Optimization |

| |

| Priority ↓ |

+-------------------------------+

↓ Selected Items

+-------------------+

| SPRINT BACKLOG |

+-------------------+

EXAMPLE

For an e-commerce application, the Product Backlog may include:

• User authentication

• Product catalog

• Shopping cart

• Payment gateway

• Order tracking

High-value items like login and checkout are placed at the top.

CONCLUSION
The Product Backlog ensures transparency, prioritization, and adaptability in Agile projects, enabling teams to
deliver maximum value incrementally and respond effectively to change.

*Unit : Staffing & Team Dynamics* - Explain Tuckman’s stages of team development (Forming, Storming, Norming,
Performing, Adjourning).

Tuckman’s Stages of Team Development (Staffing & Team Dynamics – SPM)

INTRODUCTION

Tuckman’s Team Development Model explains how teams evolve through predictable stages to become effective. It
helps project managers understand team behavior, conflicts, and performance at different phases.

MAIN ANSWER

1) Forming

• Team members are introduced and get acquainted.

• Roles, objectives, and expectations are unclear.

• High dependence on the project manager for guidance.

• Communication is formal and polite.

Outcome: Team orientation and initial understanding.

2) Storming

• Team members express differences in opinions and working styles.

• Conflicts may arise over roles, authority, and decisions.

• Productivity may decrease temporarily.

• Requires strong conflict management by the leader.

Outcome: Resolution of conflicts and clarification of roles.

3) Norming

• Team establishes norms, standards, and trust.

• Cooperation and collaboration improve significantly.

• Roles and responsibilities are clearly accepted.

• Communication becomes open and constructive.

Outcome: Team cohesion and stable working relationships.

4) Performing

• Team functions at high efficiency and productivity.

• Members are self-motivated and self-directed.

 • Focus is on task completion and goal achievement.

• Minimal supervision is required.

Outcome: Optimal team performance and successful results.

5) Adjourning

• Team is disbanded after project completion.

• Focus shifts to documentation, evaluation, and closure.

• Members may experience satisfaction or separation anxiety.

• Recognition and feedback are important.

Outcome: Formal project closure and team dissolution.

SUMMARY TABLE

Stage Key Focus

Forming Orientation and role understanding

Storming Conflict and disagreement

Norming Cooperation and trust

Performing High productivity

Adjourning Project closure

EXAMPLE

In a software development team, members initially learn requirements (Forming), disagree on design approaches
(Storming), agree on coding standards (Norming), deliver high-quality software (Performing), and finally disperse
after release (Adjourning).

CONCLUSION

Tuckman’s model helps project managers anticipate team behavior, apply suitable leadership strategies, and guide
teams toward high performance and successful project completion.

- Explain the influencing elements of Organizational Behavior.

Influencing Elements of Organizational Behavior (Staffing & Team Dynamics – SPM)

INTRODUCTION

Organizational Behavior (OB) is the study of individual, group, and organizational actions and how they affect
performance, productivity, and effectiveness within an organization.
MAIN ANSWER

The influencing elements of Organizational Behavior are broadly classified into three levels:

1) Individual-Level Factors

These factors influence how an individual behaves in an organization.

1. Personality

o Individual traits such as attitude, emotional stability, and openness affect work behavior.

2. Perception

o How individuals interpret situations, people, and events influences decision-making.

3. Motivation

o Internal and external forces that drive individuals to work (e.g., incentives, recognition).

4. Learning

o Continuous learning affects skill development and adaptability.

5. Attitudes and Values

o Job satisfaction, commitment, and ethics directly impact performance and retention.

2) Group-Level Factors

These factors arise due to interaction among individuals.

1. Group Dynamics

o Interaction patterns, cooperation, and conflict within teams affect productivity.

2. Leadership

o Leadership style (autocratic, democratic, transformational) influences team morale and direction.

3. Communication

o Clear and effective communication improves coordination and reduces misunderstandings.

4. Power and Politics

o Authority distribution and informal influence affect decision-making and behavior.

5. Conflict Management

o How conflicts are handled impacts team harmony and performance.

3) Organizational-Level Factors

These factors are related to the overall structure and culture of the organization.

1. Organizational Structure

o Hierarchy, roles, and reporting relationships shape work behavior and coordination.

2. Organizational Culture
 o Shared beliefs, norms, and values influence employee behavior and work ethics.

3. Policies and Procedures

o Rules and formal systems guide acceptable behavior and performance standards.

4. Technology and Work Environment

o Tools, infrastructure, and physical environment affect efficiency and job satisfaction.

5. Reward and Control Systems

o Performance appraisal, incentives, and control mechanisms influence employee motivation.

EXAMPLE

In a software organization, motivated developers (individual factor), effective Agile teams (group factor), and a
collaborative culture with flexible policies (organizational factor) lead to high productivity and innovation.

CONCLUSION

Organizational Behavior is influenced by individual, group, and organizational elements. Understanding these
factors helps managers improve performance, teamwork, and organizational effectiveness in software projects.

- Describe the Oldham-Hackman Job Characteristics Model with an example.

Oldham–Hackman Job Characteristics Model (Staffing & Team Dynamics – SPM)

INTRODUCTION

The Oldham–Hackman Job Characteristics Model (JCM) explains how job design influences employee motivation,
satisfaction, and performance by identifying core job attributes and their psychological impact.

MAIN ANSWER

Core Job Characteristics

1. Skill Variety

o Degree to which a job requires different skills and talents.

o High variety increases interest and motivation.

2. Task Identity

o Degree to which a job involves completion of a whole, identifiable piece of work.

o Enhances sense of accomplishment.

3. Task Significance

o Degree to which a job has impact on others or the organization.

o Increases meaningfulness of work.

 4. Autonomy

o Degree of freedom and independence in scheduling and performing work.

o Leads to responsibility for outcomes.

5. Feedback

o Degree to which the job provides clear information about performance.

o Enables self-correction and learning.

Critical Psychological States

• Experienced Meaningfulness of Work

← Skill Variety + Task Identity + Task Significance

• Experienced Responsibility for Outcomes

← Autonomy

• Knowledge of Results
← Feedback

Outcomes of the Model

• High internal work motivation

• High job satisfaction

• High quality performance

• Low absenteeism and turnover

EXAMPLE (Software Project Context)

Job: Software Developer in an Agile team

• Skill Variety: Design, coding, testing, code review

• Task Identity: Develops a complete feature (user story)

• Task Significance: Feature used by thousands of users

• Autonomy: Chooses implementation approach

• Feedback: Continuous feedback via testing and Sprint reviews

Result: High motivation, ownership, and productivity.

CONCLUSION

The Oldham–Hackman Model demonstrates that well-designed jobs enhance motivation and performance. By
increasing core job characteristics, organizations can improve employee satisfaction and effectiveness, especially in
software project teams.
- Define Virtual/Dispersed Teams and discuss strategies and challenges in managing them.

Virtual / Dispersed Teams – Definition, Challenges and Management Strategies (Staffing & Team Dynamics – SPM)

INTRODUCTION

Virtual (Dispersed) Teams are project teams whose members are geographically separated and collaborate using
communication and collaboration technologies to achieve common project goals.

DEFINITION

• A Virtual / Dispersed Team is a group of individuals working on the same project but located at different
geographical locations, time zones, or organizations, communicating primarily through electronic media.

CHALLENGES IN MANAGING VIRTUAL / DISPERSED TEAMS

1. Communication Barriers

o Lack of face-to-face interaction may cause misunderstanding and delays.

2. Time Zone Differences

o Overlapping work hours are limited, affecting coordination and meetings.

3. Cultural Differences

o Differences in language, work culture, and values can lead to conflicts.

4. Trust and Team Cohesion

o Reduced informal interaction makes trust building difficult.

5. Monitoring and Control

o Difficult to track progress and productivity remotely.

6. Technology Dependence

o Performance depends heavily on network reliability and tools.

STRATEGIES FOR MANAGING VIRTUAL / DISPERSED TEAMS

1. Effective Communication Tools

o Use tools like video conferencing, chat platforms, project management software.

2. Clear Roles and Responsibilities

o Define tasks, authority, and expectations explicitly.

3. Regular Meetings and Updates

o Conduct daily stand-ups, weekly reviews, and status reporting.

4. Establish Common Working Norms

o Set standards for response time, documentation, and communication etiquette.

 5. Build Trust and Team Bonding

o Encourage virtual team-building activities and informal interactions.

6. Strong Leadership and Coordination

o Project manager should provide clear direction, motivation, and conflict resolution.

7. Time Zone Management

o Rotate meeting timings and ensure fair distribution of inconvenience.

EXAMPLE

In a global software development project, developers in India, testers in Europe, and clients in USA collaborate using
tools like Jira, Git, Zoom, following defined communication protocols to ensure smooth execution.

CONCLUSION

Virtual teams offer flexibility and access to global talent but introduce communication and coordination
challenges. With proper strategies, tools, and leadership, virtual teams can be highly effective and productive in
modern software project management.

- Define Motivation and explain Theory Z and its features.

Motivation and Theory Z (Staffing & Team Dynamics – SPM)

INTRODUCTION

Motivation is a key factor influencing employee performance, commitment, and productivity. Management
theories like Theory Z explain how organizational practices can enhance long-term motivation and loyalty.

DEFINITION OF MOTIVATION

• Motivation is the internal and external driving force that stimulates individuals to act, directs their
behavior, and sustains effort toward achieving organizational and personal goals.

THEORY Z (By William Ouchi)

Theory Z emphasizes long-term employment, trust, collective decision-making, and employee well-being, inspired
by Japanese management practices and adapted to modern organizations.

FEATURES OF THEORY Z

1. Long-Term Employment

o Employees are offered job security.

o Builds loyalty and commitment to the organization.

 2. Collective Decision-Making

o Decisions are taken jointly by management and employees.

o Encourages participation and ownership.

3. Individual Responsibility

o Although decisions are collective, responsibility is individual.

o Promotes accountability.

4. Slow Evaluation and Promotion

o Performance appraisal and promotion are gradual and long-term.

o Focus on overall contribution, not short-term results.

5. Holistic Concern for Employees

o Organization shows concern for personal, social, and family needs.

o Improves job satisfaction and morale.

6. Trust-Based Relationship

o High level of mutual trust between employees and management.

o Reduces need for strict supervision.

7. Informal Control with Formal Measures

o Relies on self-discipline and peer control.

o Formal rules exist but are less rigid.

EXAMPLE

In a software company following Theory Z, developers are retained long-term, involved in architectural decisions,
evaluated over multiple projects, and supported through flexible work policies—leading to high motivation and low
attrition.

CONCLUSION

Motivation drives performance, and Theory Z enhances motivation through trust, job security, and employee
involvement. It is especially effective in knowledge-based organizations like software development firms, where
commitment and collaboration are critical