NPTEL • IIT KHARAGPUR • SOFTWARE PROJECT MANAGEMENT WEEK 3 Project Evaluation & Programme Management Exam-focused theory, formulas, diagrams, worked examples, and Assignment 3 explained option by option THEORY • CALCULATIONS • MCQ/MSQ WEEK 3 • SOFTWARE PROJECT MANAGEMENT 01 How to study this deck WEEK 3 • SOFTWARE PROJECT MANAGEMENT 02 • First learn the business case and project portfolio management (PPM). • Then master cost/benefit categories and evaluation methods; practice the formulas, not just the definitions. • Study risk evaluation methods and distinguish project risk from business risk. • Finish with programme management, benefits management, and all 10 Assignment 3 questions. • Diagrams on cash flow, risk matrices, decision trees, break-even analysis, and programme dependencies are redrawn as study visuals. EXAM TAKEAWAY • Source basis: the five Week 3 lecture PDFs and the uploaded NPTEL Assignment 3. Week 3 concept map Project evaluation connects financial analysis with risk and organizational outcomes WEEK 3 • SOFTWARE PROJECT MANAGEMENT 03 Business case Should the project start? → Cost-benefit What are costs and benefits? → Evaluation Which investment is best? → Risk evaluation How uncertain are outcomes? → Programme How do projects combine to deliver benefits? The business case focuses on whether a project is justified; programme management focuses on coordinated change and realized benefits. Business case: purpose and feasibility WEEK 3 • SOFTWARE PROJECT MANAGEMENT 04 • The lecture treats the feasibility study as the “business case.” • Its main focus is whether developing the software is financially and technically feasible. • It justifies starting the project and should show benefits exceeding development, implementation, and operational/production costs. • It must take account of business risks, not merely technical delivery risks. • Feasibility types named in the lecture: technical, financial, and operational. EXAM TAKEAWAY • A business case is the justification for doing the project—not the detailed implementation itself. Contents of a business case / feasibility study WEEK 3 • SOFTWARE PROJECT MANAGEMENT 05 Section What it should explain 1. Introduction/background Problem to solve or opportunity to exploit. 2. Proposed project Brief project scope. 3. Market Likely demand for the product or service. 4. Organizational/operational infrastructure How the organization may need to change. 5. Benefits Preferably expressed in financial terms; client assesses value. 6. Outline implementation plan How implementation will happen and likely disruption. 7. Costs Estimate based on the implementation plan. 8. Financial case Combine costs and benefits to establish project value. 9. Risks Project risks and business risks; business risk is the case’s main focus. 10. Management plan Plan for smooth management of the organization. Feasibility: three angles WEEK 3 • SOFTWARE PROJECT MANAGEMENT 06 Technical feasibility • Can required functionality be achieved with currently available, affordable technology? • Include the cost of adopted technology in the financial assessment. • Question: can we build it with the technology and skills available? Financial feasibility • Identify development, setup, and operational costs. • Estimate and value the expected benefits. • Check whether benefits justify costs and whether funding is possible. REMEMBER • Operational feasibility asks whether the solution can be used and fit into the organization’s operations. Project Portfolio Management (PPM) WEEK 3 • SOFTWARE PROJECT MANAGEMENT 07 • Provides an overview of all projects an organization is undertaking. • Prioritizes allocation of resources across projects. • Decides which new projects should be accepted and which existing projects should be dropped. • Evaluates proposals, assesses project risks, shares resources, accounts for dependencies, removes duplication, and checks that necessary developments are not missed. EXAM TAKEAWAY • PPM looks across the collection of projects; project management focuses on delivering an individual project. Three elements of PPM Memorize the order: define → manage → optimize WEEK 3 • SOFTWARE PROJECT MANAGEMENT 08 1. Portfolio definition Create a central record; define what belongs in the portfolio. → 2. Portfolio management Record and assess actual project costs and performance. → 3. Portfolio optimization Use the information to balance value, risk, and resources. A portfolio can balance risky/high-value projects with safer/lower-value projects. PPM: benefits and limitations WEEK 3 • SOFTWARE PROJECT MANAGEMENT 09 Benefits / purpose • Creates visibility across projects. • Supports resource prioritization and project acceptance/ rejection. • Highlights dependencies and duplicated effort. • Allows small ad-hoc tasks (such as quick fixes) to be handled outside the formal portfolio. Limitations noted in the lecture • Full-time project staff may effectively be part-time because routine work still competes for their time. • If some projects are excluded, the official portfolio may not accurately reflect all organizational activity. • Portfolio decisions depend on the quality and completeness of the recorded information. REMEMBER • A portfolio is only as useful as the projects and resource commitments it represents. Evaluating an individual project WEEK 3 • SOFTWARE PROJECT MANAGEMENT 10 • Technical assessment: evaluate whether the required functionality can be achieved with affordable current technology. • Financial assessment / cost-benefit analysis: identify all costs, identify and value benefits, and check whether benefits exceed costs. • Cost categories named in the lecture: development (e.g., staff salaries), setup (e.g., hardware, recruitment, training), and operational (running the system after installation). • Technology cost must be considered in the financial assessment. EXAM TAKEAWAY • Technical feasibility and financial justification are complementary—not interchangeable. Cash-flow forecasting WEEK 3 • SOFTWARE PROJECT MANAGEMENT 11 • A cash-flow forecast indicates when expenditure and income will occur. • Development costs (equipment purchases, staff payments, etc.) occur before product income arrives; these expenses cannot simply wait for revenue. • After release, income may gradually repay earlier costs. • Forecast timing to determine whether expenses can be funded from own resources or borrowing. EXAM TAKEAWAY • A project can look profitable overall and still have a cash-flow problem if costs arrive before income. Typical product life-cycle cash flow Interpret the curve: early expenditure precedes income WEEK 3 • SOFTWARE PROJECT MANAGEMENT 12 Development Cash outflow → Release Costs still need recovery → Growth Income rises; cumulative cash position improves → Mature phase Income continues → Later life Income may decline The lecture’s cash-flow graphic dips below zero during early spending, rises into positive territory after release, and gradually declines later. It illustrates timing, not exact values. Five steps of cost-benefit analysis WEEK 3 • SOFTWARE PROJECT MANAGEMENT 13 1. Identify List costs and benefits → 2. Categorize Classify each item → 3. Select method Choose evaluation technique → 4. Interpret Compare results and uncertainty → 5. Act Choose and document a course The result should lead to a decision and a feasibility report with findings and recommendations. Identifying costs, benefits, and opportunity cost WEEK 3 • SOFTWARE PROJECT MANAGEMENT 14 • Some costs are easy to identify (e.g., the purchase price of a computer); direct benefits may map closely to direct costs, such as savings from reducing an activity’s cost. • Some direct costs/benefits are estimates and remain uncertain (the lecture gives a bad-debt allowance as an example). • Opportunity cost/benefit is what is forgone by selecting one alternative rather than another. • Do not omit difficult-to-measure items simply because they are uncertain. EXAM TAKEAWAY • Opportunity cost is about the alternative you give up. Cost/benefit classification: a quick map WEEK 3 • SOFTWARE PROJECT MANAGEMENT 15 Classification Meaning Lecture-style examples Tangible Can be measured/quantified relatively readily. Hardware/software purchase; staff salaries; training. Intangible Known to exist, but monetary value is hard to measure. Employee morale, corporate image, customer satisfaction. Direct Can be specifically associated with the project/activity. Development, setup, operational costs; a specific software purchase. Indirect / overhead Not directly associated with one system/activity. Insurance, lighting, air conditioning, computer-centre protection. Fixed Constant regardless of usage volume (lecture examples include depreciation, exempt salaries, insurance). Straight-line depreciation; fixed salary. Variable Changes with work volume and continues during operation. Computer forms consumed as processing/report length grows. Tangible vs intangible WEEK 3 • SOFTWARE PROJECT MANAGEMENT 16 Tangible costs / benefits • Measured or quantified with relative ease. • Costs: hardware/software purchase, personnel training, employee salaries. • Benefits: fewer hours to complete jobs; reports produced without errors. Intangible costs / benefits • Known or expected but difficult to assign an accurate financial value. • Costs: morale problems, damage to company image, downtime effects that are hard to price. • Benefits: improved customer satisfaction or corporate image. REMEMBER • The lecture explicitly says both tangible and intangible costs and benefits should be considered. Direct vs indirect WEEK 3 • SOFTWARE PROJECT MANAGEMENT 17 Direct • A monetary figure can be associated with the project. • Examples: a specific box of diskettes, development cost, setup cost, operational cost. • Direct benefit: a new online system handles 25% more transactions per day. Indirect • Results from operations not directly associated with a particular system/activity; often called overhead. • Examples: insurance, maintenance, heat/fire protection, lighting, air conditioning. • Indirect benefits arise as a by-product of another activity or system. REMEMBER • Direct means traceable to the project; indirect means shared or incidental. Fixed vs variable costs and benefits WEEK 3 • SOFTWARE PROJECT MANAGEMENT 18 Fixed • Costs are constant regardless of system use; lecture examples include straight-line depreciation, exempt salaries, and insurance. • Fixed benefits do not change with usage; example: a 20% reduction in personnel can create recurring monthly savings. Variable • Costs vary with work volume and continue while the system operates. • Example: computer forms consumed in proportion to processing/report length. • Variable benefits also vary with usage; example: time saved preparing notices depends on the number of notices. REMEMBER • Classify based on what causes the amount to change—not whether the amount is large or small. Seven cost-benefit evaluation techniques WEEK 3 • SOFTWARE PROJECT MANAGEMENT 19 Technique Core question Net benefit / net profit How much net cash benefit over the project’s life? Payback period When is the initial investment recovered? Return on investment (ROI) What average annual return does the investment produce? Present value (PV) What is a future amount worth today? Net present value (NPV) What is the total of discounted positive and negative cash flows? Internal rate of return (IRR) What discount rate makes NPV equal zero? Break-even analysis At what usage/volume do current and candidate system costs become equal? Net profit / net benefit analysis WEEK 3 • SOFTWARE PROJECT MANAGEMENT 20 • Net profit is the sum of project cash flows over the project lifetime: total income minus total outgoings. • Year 0 represents costs before the system becomes operational. • Lecture example cash flows: −100,000; +10,000; +10,000; +10,000; +20,000; +100,000. • Sum = 50,000 net profit. • Limitation: ignores when the cash flows occur, so two projects with the same net profit can have different timing and investment profiles. EXAM TAKEAWAY • Net profit is simple, but it ignores the time value of money.