Unit 1: Introduction to Software Project Management - Subjective Questions

A project is a temporary endeavor undertaken to create a unique product, service, or result. It has a definite beginning and ending and is carried out to achieve specific objectives within constraints such as time, cost, scope, and quality.

Essential characteristics of a project:

• Temporary nature: It has a defined start date and completion date.
• Unique outcome: The result, product, or service is different from routine outputs.
• Specific objectives: The project is initiated to achieve clearly defined goals.
• Progressive elaboration: Project details become clearer as planning and execution continue.
• Resource constraints: It uses limited people, money, tools, and infrastructure.
• Interrelated activities: Several tasks must be coordinated to produce the desired result.
• Risk and uncertainty: The outcome may be affected by technical, financial, organizational, or external risks.

Routine operations are continuous and repetitive, whereas projects are temporary and designed to produce a unique outcome.

A software project is a planned and controlled set of activities undertaken to develop, modify, deploy, or maintain software that satisfies defined customer and organizational requirements.

Differences between software projects and other projects:

• Intangible product: Software cannot be physically inspected like a building, machine, or bridge.
• High complexity: A small software system may contain a large number of interacting components and possible execution paths.
• Changeability: Software is comparatively easy to modify, so requirements often change during development.
• Development-focused cost: Most cost is associated with human effort rather than raw materials or manufacturing.
• Difficult estimation: Effort and schedule estimation are affected by uncertain requirements, technical challenges, and productivity differences.
• Limited visibility: Progress cannot always be judged by examining a partially completed product.
• Maintenance-intensive: A software product may require continuous corrective, adaptive, perfective, and preventive maintenance.
• Technology dependence: Tools, platforms, programming languages, and infrastructure may change during the project.

Therefore, software project management must give particular attention to requirements, communication, technical risk, quality, and change control.

Software production is primarily an intellectual and knowledge-intensive activity involving analysis, design, coding, testing, deployment, and maintenance.

Nature of software production:

• Creative and analytical: Developers transform abstract requirements into algorithms, designs, and executable programs.
• Mostly human-centered: The main production resource is the skill, experience, and collaboration of the development team.
• Non-physical output: Software has no physical form and is represented through source code, binaries, documentation, and configurations.
• High variability: Projects differ in domain, technology, size, complexity, and customer expectations.
• Iterative development: Requirements and designs are often refined through feedback and successive releases.
• Difficult measurement: Productivity and progress are harder to measure than the number of manufactured physical items.
• Low replication cost: After development, software can generally be copied at a very low marginal cost.
• Maintenance through change: Improvements and corrections modify the existing product rather than replacing worn physical parts.

Manufacturing mainly replicates a stable design, while software development creates and evolves the design itself. This makes planning, estimation, communication, and quality control especially important.

Software project management coordinates technical, organizational, and business activities so that the project achieves its objectives.

Major activities include:

• Project initiation: Define the business need, project purpose, stakeholders, and feasibility.
• Scope definition: Establish what the project will and will not deliver.
• Business planning: Determine objectives, expected benefits, target users, market demand, and required infrastructure.
• Proposal preparation: Present the solution, schedule, resources, costs, risks, and commercial terms.
• Effort and cost estimation: Estimate staff effort, duration, infrastructure, and financial requirements.
• Planning and scheduling: Break the work into tasks, assign responsibilities, identify dependencies, and establish milestones.
• Requirement management: Elicit, analyze, document, validate, and control requirements.
• Resource management: Organize people, tools, technology, facilities, and budgets.
• Risk management: Identify, analyze, prioritize, monitor, and respond to risks.
• Quality management: Define standards, reviews, testing activities, and acceptance criteria.
• Communication and reporting: Keep stakeholders informed about progress, issues, decisions, and changes.
• Change control: Evaluate and authorize changes to scope, schedule, cost, or requirements.
• Project closure: Obtain acceptance, deliver the product, document lessons learned, and release resources.

The primary objective of software project management is to deliver an acceptable software product while balancing scope, time, cost, quality, and risk.

Key objectives are:

• Deliver the required scope: Ensure that the software satisfies agreed functional and non-functional requirements.
• Complete the project on time: Establish a realistic schedule and monitor progress against milestones.
• Control project cost: Use accurate estimates, budgets, and expenditure monitoring.
• Maintain product quality: Apply standards, reviews, testing, defect prevention, and quality assurance.
• Manage risks: Reduce the probability and impact of events that may harm the project.
• Use resources effectively: Assign suitable personnel and make appropriate use of tools and infrastructure.
• Satisfy stakeholders: Maintain effective communication and align the product with customer and business expectations.
• Control changes: Prevent uncontrolled expansion of scope and evaluate requested changes systematically.
• Ensure legal and contractual compliance: Meet licensing, privacy, security, intellectual property, and contractual obligations.
• Support organizational learning: Record decisions, lessons learned, and reusable practices.

Effective management creates visibility, coordinates the team, supports informed decisions, and increases the likelihood of project success.

Software projects frequently experience problems because software work involves uncertainty, changing expectations, and complex human and technical interactions.

Common problems and causes:

• Unclear requirements: Stakeholders may not know exactly what they need, or requirements may be incomplete and ambiguous.
• Scope creep: New features are added without properly evaluating their effect on schedule, cost, and resources.
• Unrealistic estimates: Estimates may be based on insufficient information, excessive optimism, or inappropriate historical data.
• Schedule slippage: Delays can result from technical difficulties, dependencies, staff shortages, or late decisions.
• Cost overruns: Additional effort, infrastructure expenses, rework, and uncontrolled changes may exceed the budget.
• Poor communication: Misunderstandings between customers, managers, analysts, and developers produce incorrect work.
• Weak quality control: Inadequate reviews and testing allow defects to accumulate.
• Technology risks: New or immature technologies may not perform as expected.
• Resource and skill shortages: The project may lack people with the required technical or domain expertise.
• Poor stakeholder involvement: Delayed feedback can cause the team to develop an unsuitable product.
• Legal and compliance failures: Improper use of software, data, or third-party components may create liability.

These problems can be reduced through realistic planning, continuous monitoring, stakeholder participation, risk management, and disciplined change control.

Risk reduction is the systematic process of lowering the probability that a risk will occur, reducing its possible impact, or preparing an effective response if it occurs.

Main steps:

• Risk identification: List technical, schedule, cost, requirement, organizational, legal, and external risks.
• Risk analysis: Estimate the probability and impact of each risk. A simple risk exposure measure is:
  
• Risk prioritization: Focus management attention on risks with high exposure or severe consequences.
• Risk avoidance: Change the project approach to eliminate the risk, such as selecting a proven technology instead of an immature one.
• Risk mitigation: Take preventive action to reduce probability or impact, such as prototyping a difficult component.
• Risk transfer: Shift responsibility or financial impact through insurance, outsourcing, or suitable contractual arrangements.
• Risk acceptance: Accept a low or unavoidable risk while preparing a contingency response.
• Risk monitoring: Review risks regularly and track warning signs, owners, actions, and changing exposure.
• Contingency planning: Define what will be done if the risk materializes.

Risk reduction should begin during initiation and continue throughout the project rather than being performed only after problems appear.

Software project management is important because it provides the structure needed to convert business needs into a successful software product.

Importance to the organization:

• Aligns software development with strategic and business objectives.
• Supports realistic decisions about feasibility, investment, staffing, and technology.
• Controls cost, schedule, scope, and resource usage.
• Identifies risks before they become expensive problems.
• Improves productivity through planning, coordination, and reuse of knowledge.
• Provides progress visibility to management and other decision-makers.
• Supports compliance with contractual, legal, security, and quality requirements.
• Increases the predictability of project outcomes.

Importance to customers:

• Clarifies requirements, deliverables, responsibilities, and acceptance criteria.
• Encourages regular communication and early feedback.
• Reduces the chance of receiving software that does not meet business needs.
• Improves confidence in cost, schedule, quality, and support arrangements.
• Provides a controlled process for handling changes.

Without effective management, technically capable teams may still fail because of poor requirements, weak coordination, inadequate risk control, or unrealistic commitments.

Project scope defines the boundaries of the project by specifying the work required to produce the agreed deliverables and the work excluded from the project.

A software project scope statement should include:

• Project purpose: The business problem or opportunity being addressed.
• Objectives: Measurable results the project must achieve.
• Product description: A concise description of the software and its expected capabilities.
• Major deliverables: Software components, documentation, training, reports, or services to be provided.
• Functional boundaries: Features and functions included in the product.
• Non-functional expectations: Performance, security, usability, reliability, scalability, and compatibility requirements.
• Exclusions: Explicitly state what is outside the project to reduce misunderstanding.
• Assumptions: Conditions considered true during planning.
• Constraints: Limitations involving budget, schedule, technology, standards, or resources.
• Acceptance criteria: Conditions that must be satisfied for deliverables to be accepted.
• Stakeholders and dependencies: Relevant parties and external systems or activities on which the project depends.

A clear scope statement acts as a baseline for estimation, scheduling, requirements management, change control, and acceptance.

Project objectives describe the results the project is expected to achieve. Project scope describes the work and product boundaries required to achieve those results.

Differences:

• Objectives answer: "What benefits or results must be achieved?"
• Scope answers: "What work and deliverables are included?"
• Objectives are expressed as targets, such as reducing processing time by a specified amount.
• Scope identifies features, interfaces, documents, services, and exclusions.
• Objectives are used to judge whether the project provides value.
• Scope is used to control work and prevent unauthorized additions.

Why both are necessary:

• Clear objectives align the project with business needs.
• Clear scope prevents different stakeholders from having different expectations.
• Estimates and schedules depend on a defined scope.
• Acceptance criteria can be related to measurable objectives and deliverables.
• Change requests can be evaluated against the approved objectives and scope.
• The project team can prioritize work when objectives and boundaries are known.

For example, an objective may be to reduce customer service response time by , while the scope may include developing a ticketing system, integrating it with customer records, and providing user training.

Business planning determines whether a software project is valuable, feasible, and aligned with organizational priorities.

Typical process:

• Identify the business need: Define the problem, opportunity, inefficiency, or regulatory requirement motivating the project.
• Determine objectives: State measurable business outcomes, such as increased revenue, reduced cost, improved service, or better compliance.
• Identify stakeholders: Determine who sponsors, funds, uses, manages, supports, and is affected by the system.
• Analyze the target environment: Study current processes, competitors, users, infrastructure, and organizational capabilities.
• Forecast product demand: Estimate expected users, transactions, sales, adoption, growth, and changing market needs.
• Assess infrastructure: Determine hardware, networks, cloud services, security, support, and integration requirements.
• Evaluate alternatives: Compare possible technical and business solutions, including building, buying, outsourcing, or improving an existing system.
• Estimate benefits, effort, cost, and schedule: Develop enough information for an informed investment decision.
• Identify risks and legal issues: Examine uncertainty, regulations, contracts, intellectual property, privacy, and security obligations.
• Prepare a business case or proposal: Present the recommended approach, expected value, required resources, and implementation plan.
• Obtain approval: Secure authorization, funding, and an accountable sponsor before detailed execution begins.

Project infrastructure is the set of technical, organizational, physical, and procedural facilities required to develop, deploy, operate, and support a software product.

Important considerations include:

• Development environment: Programming languages, frameworks, integrated development environments, build tools, and repositories.
• Hardware and computing capacity: Developer machines, servers, storage, processing capacity, and backup facilities.
• Network and communication: Connectivity, bandwidth, remote access, collaboration tools, and communication channels.
• Deployment platform: On-premises servers, cloud infrastructure, mobile platforms, web hosting, or hybrid environments.
• Testing facilities: Test environments, test data, automation tools, performance tools, and security testing resources.
• Security infrastructure: Identity management, access controls, encryption, monitoring, and incident response.
• Integration facilities: Interfaces with databases, enterprise systems, third-party services, and legacy applications.
• Organizational support: Procurement, technical support, training, administration, and help-desk capabilities.
• Configuration and release management: Version control, continuous integration, artifact storage, and deployment procedures.
• Standards and policies: Coding standards, documentation rules, quality procedures, and compliance requirements.

Infrastructure should be assessed for availability, capacity, compatibility, scalability, cost, security, and long-term support.

Demand forecasting estimates how many customers, users, transactions, or deployments a software product may have over a future period. It supports both business decisions and technical planning.

Importance of demand forecasting:

• Capacity planning: Helps determine servers, storage, network bandwidth, and database capacity.
• Financial planning: Supports revenue projections, investment decisions, pricing, and return-on-investment analysis.
• Staffing decisions: Indicates the support, operations, development, and sales resources required.
• Scalability planning: Helps identify whether the architecture must support future growth.
• Release planning: Allows features and versions to be prioritized according to expected customer demand.
• Risk reduction: Prevents overinvestment in an unwanted product and reduces the risk of under-preparing for rapid adoption.
• Infrastructure budgeting: Provides a basis for estimating cloud, hosting, licensing, and maintenance costs.
• Service-level planning: Supports decisions about performance, availability, response time, and support commitments.

Forecasts may use historical data, market research, customer surveys, competitor analysis, pilot results, and expert judgment. Because forecasts are uncertain, assumptions should be documented and sensitivity analysis should be performed for optimistic, expected, and pessimistic scenarios.

A well-defined software project has enough clarity and structure to guide planning, execution, monitoring, and acceptance.

Important characteristics include:

• Clear purpose: The project addresses a recognized business or user need.
• Measurable objectives: Success can be evaluated using defined indicators.
• Defined scope: Deliverables, boundaries, exclusions, assumptions, and constraints are documented.
• Identified stakeholders: Roles, responsibilities, authority, and communication needs are known.
• Realistic feasibility: Technical, economic, operational, legal, and schedule feasibility have been considered.
• Agreed requirements: Requirements are sufficiently understood and prioritized for planning.
• Defined deliverables: Outputs and acceptance criteria are clear.
• Planned resources: Required staff, skills, tools, infrastructure, and budget are identified.
• Realistic estimates: Effort, cost, and duration are based on available information and suitable methods.
• Risk awareness: Major uncertainties have owners and response strategies.
• Governance and control: Reporting, decision-making, quality assurance, configuration management, and change control are established.
• Business alignment: The expected product and benefits support organizational strategy.

These characteristics improve predictability and reduce disputes about what the project is expected to accomplish.

A software project proposal is a formal document submitted to a customer, sponsor, or decision-making body to recommend a solution and obtain approval, funding, or a contract.

Major contents of an effective proposal:

• Executive summary: Brief statement of the problem, proposed solution, benefits, cost, and schedule.
• Background and business need: Explanation of the current situation and reason for undertaking the project.
• Objectives and scope: Measurable objectives, deliverables, inclusions, exclusions, and assumptions.
• Proposed solution: Architecture, technologies, development approach, and major product features.
• Requirements understanding: Summary of functional, non-functional, integration, and compliance requirements.
• Project organization: Team structure, roles, responsibilities, skills, and governance.
• Development plan: Activities, milestones, dependencies, quality practices, and reporting arrangements.
• Effort, cost, and schedule: Resource requirements, estimated duration, pricing, payment terms, and major assumptions.
• Risk management: Significant risks, mitigation actions, and contingency arrangements.
• Infrastructure and support: Required environments, deployment approach, training, warranty, and maintenance.
• Legal and contractual terms: Ownership, licensing, confidentiality, data protection, liability, and acceptance conditions.
• Evaluation criteria: Information that allows the recipient to compare the proposal with alternatives.

A strong proposal is realistic, evidence-based, clear about assumptions, and aligned with the customer's business objectives.

Effort estimation is the process of predicting the amount of human work required to complete a software project or a defined set of tasks. It is usually expressed in person-hours, person-days, or person-months.

Factors influencing effort:

• Product size: Number of functions, screens, interfaces, components, or source statements.
• Complexity: Difficulty of algorithms, business rules, integrations, data structures, and user interactions.
• Requirement stability: Frequently changing requirements increase analysis, rework, and testing effort.
• Quality expectations: High reliability, performance, security, or safety requirements require additional work.
• Team capability: Experience, technical skills, domain knowledge, communication, and productivity affect effort.
• Technology and tools: Familiar or mature tools may reduce effort, while new technologies increase uncertainty.
• Reuse: Reusable components can reduce development effort, although integration and customization still require work.
• Process and documentation: Reviews, testing, configuration management, compliance, and documentation add effort but improve quality.
• Project constraints: Short deadlines, distributed teams, and restricted infrastructure may increase effort.
• External dependencies: Vendors, customer decisions, legacy systems, and approvals may cause delays and rework.

Estimates should state assumptions, use more than one estimation technique where practical, include appropriate contingency, and be refined as project knowledge improves.

Software effort can be estimated using several complementary approaches. No single technique is equally reliable for every project.

Major approaches:

• Expert judgment: Experienced professionals estimate effort based on similar work and technical knowledge.
• Analogy-based estimation: The project is compared with completed projects that have similar size, complexity, technology, and team conditions.
• Top-down estimation: The total project effort is estimated first and then allocated to major phases or components.
• Bottom-up estimation: Individual tasks are identified and estimated; the total is obtained by adding task estimates and suitable contingency.
• Parametric or algorithmic models: Effort is calculated using a mathematical relationship between size, cost drivers, and productivity. A generic form is:
  
  where is effort, is estimated size, and and are calibrated parameters.
• Three-point estimation: Optimistic, most likely, and pessimistic estimates are combined to reflect uncertainty.
• Agile or velocity-based estimation: Relative size is estimated and future effort is inferred from the team's observed delivery rate.

Role of historical data:

• Provides evidence about actual productivity, defect rates, task duration, and cost.
• Helps calibrate estimation models and identify comparable projects.
• Reveals recurring risks and sources of rework.
• Improves future estimates when the data is accurate, relevant, and measured consistently.

Historical data must be adjusted for differences in technology, team capability, project size, process, and complexity.

Requirement analysis is the systematic process of discovering, examining, documenting, prioritizing, and validating what stakeholders need from a software system.

Main activities:

• Elicitation: Gather information through interviews, workshops, observation, surveys, document study, prototypes, and user stories.
• Analysis: Examine requirements for completeness, consistency, feasibility, ambiguity, dependencies, and conflicts.
• Classification and prioritization: Group requirements and rank them according to value, urgency, risk, cost, and regulatory importance.
• Specification: Document functional and non-functional requirements in an understandable and testable form.
• Modeling: Use diagrams, scenarios, data models, workflows, or prototypes to clarify behavior and structure.
• Validation: Confirm that requirements are correct, feasible, necessary, complete, consistent, and verifiable.
• Baseline and management: Approve the requirement set and control later changes through an agreed process.

Importance:

• Establishes the foundation for scope, architecture, design, coding, testing, and acceptance.
• Reduces misunderstanding and expensive rework.
• Enables realistic effort, cost, and schedule estimation.
• Provides traceability from business objectives to implemented features and tests.
• Helps stakeholders agree on priorities and trade-offs.
• Identifies risks and legal, security, performance, and usability needs early.

Poor requirements are a major cause of project failure because even a well-built system may be unacceptable if it solves the wrong problem.

Risk identification is the process of discovering and documenting uncertain events or conditions that could affect project objectives positively or negatively. Each identified risk should be described with its cause, possible event, consequence, probability, impact, owner, and proposed response.

Major categories of software project risks:

• Requirement risks: Ambiguous, incomplete, conflicting, or frequently changing requirements.
• Technical risks: Unproven technology, difficult integration, performance limitations, security weaknesses, or unsuitable architecture.
• Estimation risks: Incorrect assumptions about product size, productivity, effort, cost, or duration.
• Schedule risks: Delayed decisions, underestimated tasks, dependency failures, or unavailable resources.
• Resource risks: Staff turnover, inadequate skills, insufficient infrastructure, or budget limitations.
• Organizational risks: Weak sponsorship, changing priorities, poor governance, or internal conflicts.
• Quality risks: Inadequate testing, unclear quality standards, high defect rates, or poor maintainability.
• External risks: Vendor failure, market changes, political conditions, economic changes, or natural events.
• Legal and compliance risks: Licensing violations, privacy breaches, intellectual property disputes, and failure to meet regulations.
• Operational risks: Problems with deployment, user adoption, support, availability, or business continuity.

Identification techniques include brainstorming, checklists, interviews, lessons learned, assumption analysis, SWOT analysis, and reviews of similar projects.

Legal issues must be identified early because violations can cause financial loss, project delays, product removal, reputational damage, or legal liability.

Important legal considerations:

• Intellectual property ownership: Establish who owns source code, designs, documentation, data, and other deliverables.
• Copyright: Ensure that software, documentation, images, libraries, and other materials are used with appropriate rights.
• Open-source licensing: Review obligations associated with licenses such as permissive and copyleft licenses, including attribution and redistribution requirements.
• Software licensing: Confirm that development tools, operating systems, databases, cloud services, and third-party components are properly licensed.
• Confidentiality: Use confidentiality agreements and access controls to protect business information, source code, and trade secrets.
• Data protection and privacy: Define lawful collection, processing, storage, transfer, retention, and deletion of personal data.
• Security obligations: Address contractual and regulatory requirements for protecting systems and information.
• Contracts and procurement: Specify scope, deliverables, milestones, payment, acceptance, warranties, service levels, support, and termination rights.
• Liability and indemnity: Clarify responsibility for defects, security incidents, third-party claims, and service failures.
• Employment and outsourcing: Define ownership, confidentiality, staff responsibilities, subcontracting, and jurisdiction.
• Regulatory compliance: Consider industry-specific rules, accessibility, records retention, export restrictions, and audit requirements.

Legal review should be performed by qualified professionals, with obligations recorded in requirements, contracts, project plans, and acceptance criteria.