Establishing a Metrics Program PDF

Establishing a Metrics Program Establishing a Metrics Program A metrics collection program quantitatively assesses how the project goals are being achieved Process metrics: measure different characteristics of a project Product metrics: measure different characteristic...

Establishing a Metrics Program Establishing a Metrics Program A metrics collection program quantitatively assesses how the project goals are being achieved Process metrics: measure different characteristics of a project Product metrics: measure different characteristics of a project product Trends often more important than point-wise numbers Better if automated spm - ©2014 adolfo villafiorita - introduction to software project management 25 Product Metrics: Size Size oriented metrics: – Source lines of code – Number of classes Function oriented metrics: – Function Points – Object Points Comments: – Size metrics can be automatically collected – The count of SLOC, however, is “controversial” (see next slide) – Function oriented metrics requires trained personnel for their collection spm - ©2014 adolfo villafiorita - introduction to software project management 26 Product Metrics: Complexity Cyclomatic complexity Coupling between objects Depth of inheritance Fan-in, fan-out spm - ©2014 adolfo villafiorita - introduction to software project management 27 Product Metrics: Quality Metrics Ratio between lines of comments and lines of codes (Indication of the maintainability of a system) Cumulative number of open issues (It measures whether the project is “converging”) Error density, that is, the number of errors found per source line of code. (It helps understand whether the development process has some systematic faults.) spm - ©2014 adolfo villafiorita - introduction to software project management 28 Managing Changes, Risks, and Quality Goals of the Unit Requests for changes and changes will occur in your project The goal of this unit is understanding: – The importance of keeping a project under scope – How request for changes can positively or negatively influence your project – The techniques to manage changes spm - ©2014 adolfo villafiorita - introduction to software project management 30 The Framework The scope document formalizes the goals of a project Ideally, once the goals are fixed, the project should move on to the design/implementation phase and achieve the project goals, through a progressive refinement Any deviation from such course of action is a perturbation (it changes goals, plans, costs, outputs, work to be performed, …) Changes, however, are inevitable The goal of a sound project management, therefore, is ensuring that the change process is properly managed spm - ©2014 adolfo villafiorita - introduction to software project management 31 Fundamental Concepts Change Control is the set of practices to ensure request for changes are properly taken care of Configuration Management is the set of practices to ensure project outputs remain coherent over time Change Control and Configuration Management span over the lifecycle of the project outputs In software projects artifacts are extremely simple to change (e.g., editing a file) In software projects, connection with bug reporting/bug lifecycle spm - ©2014 adolfo villafiorita - introduction to software project management 32 Change Control Causes of Request for Changes Incompleteness or incoherencies in the project requirements or in the description of work A better comprehension of the system to be developed A technical opportunity A technical challenge A change in the external environment Non-compliance of a project deliverable spm - ©2014 adolfo villafiorita - introduction to software project management 35 A Change Control Process It runs in parallel to the other PM activities throughout the project spm - ©2014 adolfo villafiorita - introduction to software project management 36 Comments A change control board might be appointed to approve/reject changes The cost and risk of changes increase as the project moves to the delivery The process ensures a formal record is kept and and a clear procedure is set to evaluate the impact of changes Change and change management is embraced by agile methodologies (changes “treated” as requirements) spm - ©2014 adolfo villafiorita - introduction to software project management 37 Software Evolution Models What makes a Software System Software systems are made of many different artifacts (sources, libraries, external libraries, documentation, conversion scripts, databases) Software systems run in many different configurations (e.g., base/pro, versions 1 and 2, Linux/OSX/Windows) Two sources of complexity need to be addressed to develop or maintain a software product: – Identification of the artifacts – Evolution spm - ©2014 adolfo villafiorita - introduction to software project management 39 Linear Development Model Source Code replaces Source replaces Source Version 1 Code Code Version 2 Version 3 produces produces produces Application Application Application Version 1 Version 2 Version 3 spm - ©2014 adolfo villafiorita - introduction to software project management 40 Branching Development Model Source Source Source Code Code Code Version 1.1 Version 2.1 Version 2.1 Source Source Source Code replaces Code replaces Code Version 1 Version 2 Version 3 produces produces produces produces produces Application Application Application Application Application Version 1 Version 1.1 Version 2 Version 2.1 Version 3 spm - ©2014 adolfo villafiorita - introduction to software project management 41 Software Development Models Linear development: – Only one version of an application is running at any given time (Example: one-offs; many web applications are one-offs) Branching development: – Various versions of an application are running at a given time spm - ©2014 adolfo villafiorita - introduction to software project management 42 Configuration Management Configuration Management Configuration Management (CM) is a set of activities running in parallel to the development process, whose goal is establishing and maintaining system’s coherency over time – Part of the project management plan – Helps define project standards and best practices spm - ©2014 adolfo villafiorita - introduction to software project management 44 Configuration Management Main Goals Being able to build a system from a consistent set of components Being able to retrieve a software component when needed (consider: storage time, storage means) Being able to view the history of changes a system has undergone Being able to retrieve a previous version of a system Remark: closely related to the change management process spm - ©2014 adolfo villafiorita - introduction to software project management 45 Some Examples A bug is reported by a user on a COTS software we have been selling for ten years. A client requests an enhancement to a one-off system we sold in 2005. We need to reproduce/understand an odd behavior of the control software of a space exploration probe which is now orbiting Jupiter spm - ©2014 adolfo villafiorita - introduction to software project management 46 Steps and Tools: Establish Baseline The first step is “establishing what a product is” A good CM requires to: – Clearly identify the items which constitute a product – Identify the relationships among these items – Choose an appropriate identification and numbering scheme for versions – Take “snapshots”: baseline records spm - ©2014 adolfo villafiorita - introduction to software project management 47 Steps and Tools: Manage Changes The second step is “maintaining coherency over time” A good CM process requires to: – Define the “baseline record” (the starting point) – Identify and approve requests for changes (see change control) – Formally record changes and history of each item – Maintaining old versions For family of products there could be different baselines. Changes might need to be applied to one or more baseline (consider a security fix to a browser) spm - ©2014 adolfo villafiorita - introduction to software project management 48 Steps and Tools: Considerations For software development, a version control system implements various of the functions described above Tools are not sufficient: an adequate process has to be in place Semantic versioning is an example of numbering schema spm - ©2014 adolfo villafiorita - introduction to software project management 49 Version Control Systems: Main Concepts Working version: the file (or set of files we are currently editing) Repository: the storage where all versions of a file (or set of files) are kept together with additional information Repository Repository' Files Files a.each do |x| puts x end History Log a.each do |x| a.each do |x| puts x History Log puts x end end x| #a.each do | #puts x Tags #a.each do | #a.each do | x| x| #puts x Tags #end #puts x Version N. Version N. #end #end a.each do |x| commit a.each do |x| commit checkout puts x puts x end end #a.each do |x| #a.each do |x| #puts x #puts x #end #end spm - ©2014 adolfo villafiorita - introduction to software project management 50 Version Control Systems: Main Concepts In the simple case (early VCS) each file would have an independent repository Coherence is kept by assigning the same tags to all artifacts constituting a baseline More recent VCS manage sets of artifacts in an integrated way Tagging is used to mark important baseline records A VCS typically support parallel access and editing of artifacts spm - ©2014 adolfo villafiorita - introduction to software project management 51 Risk Management Motivations When we looked at project selection we just took into account financial data In the scope management document we emphasized the importance of making our goals achievable, i.e. the A in SMART... however between achievable and achieved there is a big difference. In the planning phase we had to deal with various uncertainties (estimation) and tried to deal with them generically (e.g. time buffers) We stuck to one plan (the nominal plan), but the world is non-nominal: changes, both negative and positive, will occur! spm - ©2014 adolfo villafiorita - introduction to software project management 53 Risk Management Risk management collects techniques, know-how and processes to help identify, assess, manage, and monitor risks The objectives of Project Risk Management are to increase the probability and the impact of positive events and decrease the probability and impact of events adverse to the project. spm - ©2014 adolfo villafiorita - introduction to software project management 54 Risk Management: Some Goals Understanding whether a project is worth taking Help refining the budget for the project Increase chances of ending the project successfully Increase chances of terminating the project as planned: – Within scope – Within quality – Within budget – On time spm - ©2014 adolfo villafiorita - introduction to software project management 55 Risk Management: Two Definitions “Traditionally”: – Risk is the possibility of suffering loss In project management: – (Project) Risk is an event or condition that, if it occurs has positive or negative influence on an objective * Negative outcome: menace * Positive outcome: opportunity spm - ©2014 adolfo villafiorita - introduction to software project management 56 Risk Management Used in several fields, such as: – Finance – Insurance – Engineering (safety critical, security, …) Various standards recognize the importance of risk in software development: – ISO/IEC 12207 (Information Technology - Software life cycle processes) – UNI EN 29000-3 (Guidelines for the application of ISO 9001 to software development and maintenance) – UNI ISO 10006 (Guidelines for managing projects) Various techniques (FMEA, FTA, simulation, …) have been defined and adopted to assess it. spm - ©2014 adolfo villafiorita - introduction to software project management 57 Goals of the Unit Learning the techniques to identify, assess, prioritize, manage and control project risks Learning what are the most common risks in software development projects Learning how to budget for project risks spm - ©2014 adolfo villafiorita - introduction to software project management 58 Risk Management and Project Management The Risk Management Process Define Risk Define Management Identify Risks Classify Risks Management Standards Strategies Risk Management Risk Register Risk Register Risk Plan Starndars (updated) and Risk Matrix [ new risk identified ] Monitor Risks Risk Log (updated) It runs in parallel to the other PM activities throughout the project spm - ©2014 adolfo villafiorita - introduction to software project management 61 Defining Risk Management Standards Goal: describing how risk management will be structured and performed on the project. – Output: a document (or set of documents and templates) – Part of the project management plan – Helps define project standards and best practices spm - ©2014 adolfo villafiorita - introduction to software project management 62 Define Risk Management Standards The document includes, at a minimum: – The procedures to monitor and update risks – The procedures to apply contingency plans – Who is in charge of what Added value: – Definition of risk probabilities and impacts – Risk Categories or other sources to identify risks – Reporting formats A risk management plan could be standardized and adopted organization-wide Different projects require different levels of formality in risk management spm - ©2014 adolfo villafiorita - introduction to software project management 63 Risk Identification Goal: understanding what are the risk that could potentially influence the project and document their characteristics – Risk identification is an iterative process (new risks may be identified as the project progresses; old risks may become “obsolete”) – Output: Risk Register, basis for qualitative/quantitative risk analysis spm - ©2014 adolfo villafiorita - introduction to software project management 64 Risk Identification and Classification Process (iterative): – Collect: * identify specific project risks * describe the risk – Analyze: * Identify the root causes (do not misinterpret effects as causes) * Define the risk category (impact) and probability * Identify other useful characteristics: – When it can occur or frequency of occurrence – How it manifests Output: – Risk Register spm - ©2014 adolfo villafiorita - introduction to software project management 65 Risk Identification Techniques Meetings Document Analysis Risk Breakdown Structures, Checklists, Templates Analogy spm - ©2014 adolfo villafiorita - introduction to software project management 67 Boehm’s Top Ten Causes for Project Failures Boehm developed a list of the ten most common causes for projects to fail Some of the causes mentioned in the list can be used as starting point to identify the risks applicable to a project at hand Risks include: – Personnel or subcontractors Shortfall – Unrealistic schedule and budget – Developing the wrong software functions/user interface – Gold plating (getting priorities wrong) – Ineffective change control – Technical risks spm - ©2014 adolfo villafiorita - introduction to software project management 68 Root Cause Analysis Techniques Cause-Effect Diagram (Ishikawa) Fault Trees/Failure Modes and Effect Analysis Machine Method Material Risk Measurement Man Mother Nature spm - ©2014 adolfo villafiorita - introduction to software project management 69 Fishbone Diagrams: Some starting points The 6 M's: – Machine, Method, Materials, Measurement, Man and Mother Nature (Environment) (recommended for manufacturing industry). The 8 P's: – Price, Promotion, People, Processes, Place / Plant, Policies, Procedures & Product (or Service) (recommended for administration and service industry). The 4 S's: – Surroundings, Suppliers, Systems, Skills (recommended for service industry). spm - ©2014 adolfo villafiorita - introduction to software project management 71 Risk Assessment and Risk Management Strategies Risk Assessment Goal: prioritize risks according to their impact and likeness on the project – Output: a prioritized list of risks (priority defined according to probability and impact) – Information on whether a project is worth taking – Information about what risks must be monitored spm - ©2014 adolfo villafiorita - introduction to software project management 73 Probability/Impact Frequency Why projects don’t have risks here? Why projects do not have risks Impact here? spm - ©2014 adolfo villafiorita - introduction to software project management 74 Techniques Qualitative risk analysis – Simpler – Can be used when no precise information about probabilities of risk is available Quantitative risk analysis – More systematic – Suitable for mathematical analysis – Provide figures on the (economical) impact of risks spm - ©2014 adolfo villafiorita - introduction to software project management 75 Qualitative Risk Analysis Qualitative Risk Analysis Start from – Risks Management Standard which define the scales to be adopted for probability and impact – The outputs of the risk identification phase (during which we assigned a probability to each risk) Highlight most significant risks: – By organizing risks into a risk matrix – By scoring risks Output: – Assess whether the project is worthwhile. – Decide what risks must be monitored spm - ©2014 adolfo villafiorita - introduction to software project management 77 Risk Matrix Negligible Low Moderate Severe Catastrophic Very High R1 R5 High R2 R6, R7, R8 Moderate R3 Low R4 Very Low R9, R10 spm - ©2014 adolfo villafiorita - introduction to software project management 78 Risk Matrix Decide where to set the “bar”... Negligible Low Moderate Severe Catastrophic Very High R1 R5 High R2 R6, R7, R8 Moderate R3 Low R4 Very Low R9, R10 spm - ©2014 adolfo villafiorita - introduction to software project management 79 Risk Matrix RED: Require special treatment (or drop the project) ORANGE: Need close monitoring GREEN: LOW: Standard in a project... nuisances Negligible Low Moderate Severe Catastrophic Very High R1 R5 High R2 R6, R7, R8 Moderate R3 Low R4 Very Low R9, R10 spm - ©2014 adolfo villafiorita - introduction to software project management 80 Risk Scoring Define classes of probabilities and classes of qualitative or numeric classes of impact Example – Probability: very low, low, moderate, high, very high – Impact: negligible, low, moderate, severe, catastrophic – Risk Score: low, medium, high (see previous slide) or numeric: SCORE = P xI Very Low 0.1 1 Negligible 0.1 1 Low 0.3 2 Low 0.3 2 Moderate 0.5 3 Moderate 0.5 3 High 0.7 4 Severe 0.7 4 Very High 0.9 5 Catastrophic 0.9 5 spm - ©2014 adolfo villafiorita - introduction to software project management 81 Socially constructed risk Two problems with qualitative risk – Modelers: we are “risk illiterate” (we believe some things are riskier than others, sometimes even when statistics tell us otherwise) – Models: who says what the probabilities are? How do we calculate the risk exposures objectively? (projects are one-offs) spm - ©2014 adolfo villafiorita - introduction to software project management 82 Examples of risks: Causes of Death Heart disease: 597,689 Nephritis, nephrotic syndrome, Cancer: 574,743 and nephrosis: 50,476 Chronic lower respiratory Influenza and Pneumonia: diseases: 138,080 50,097 Stroke (cerebrovascular Intentional self-harm (suicide): diseases): 129,476 38,364 Accidents (unintentional injuries): 120,859 Alzheimer's disease: 83,494 Diabetes: 69,071 Source: http://www.cdc.gov/nchs/fastats/lcod.htm (2011 data) spm - ©2014 adolfo villafiorita - introduction to software project management 83 Risk Management Strategies a.k.a. Risk Response Planning: how do we take care and exploit risks Risk Management Strategy Goal: find a treatment for the unacceptable risks and decide the strategies to apply for the remaining risks, should they occur during the project – Output: a plan with only acceptable risks – A contingency plan for each remaining significant risk spm - ©2014 adolfo villafiorita - introduction to software project management 85 The Scenario RED: Require special treatment (or drop the project) ORANGE: Need close monitoring GREEN: LOW: Standard in a project... nuisances Negligible Low Moderate Severe Catastrophic Very High R1 R5 High R2 R6, R7, R8 Moderate R3 Low R4 Very Low R9, R10 spm - ©2014 adolfo villafiorita - introduction to software project management 86 Strategies: Menaces Avoid – Change the plan to eliminate the threat (increase time, relax objectives, take corrective actions - increase time to do requirements) Transfer – Shift the negative outcome to a third party. It transfers responsibility, it does not eliminate the risk (insurance, contracts to transfer liability… they require to pay you a price) Mitigate – Reduce probability or impact (often better than trying and repair the damage; prototyping) spm - ©2014 adolfo villafiorita - introduction to software project management 87 Strategies: Opportunities Exploit – Eliminate uncertainty relate to the occurrence of the opportunity (e.g. assign more talented people, provide better quality) Share – Allocate responsibility of exploitation to a third party (joint-ventures, partnerships, …) Enhance – Modify the size of an opportunity by increasing probability and/or positive impact spm - ©2014 adolfo villafiorita - introduction to software project management 88 Strategy: common Accept – Passive: just let the team deal with the risks – Active: provide some buffer (time, money, …) Why?... Low impact or probability... Simpler to deal with the risk, if it occurs than planning a response in advance spm - ©2014 adolfo villafiorita - introduction to software project management 89 Risk Response Planning: Outputs Risk Response Plan: – Strategy (strategies) for dealing with the risks: must be concrete! – Triggers (elements used to monitor and understand whether a risk has occurred) – People responsible of monitoring the risk – People responsible of applying contingency plans spm - ©2014 adolfo villafiorita - introduction to software project management 90 The Risk Register The most common tool to list and manage risks is a spreadsheet One row per risk Each risk characterized by: – ID, Title, Description – Risk Category (if you are inclined to classifications) – Probability, Impact and, possibly, Score (PxI) – Root cause – Time-frame – Monitoring modalities (periodicity, person, reporting) – Status (active, occurred, inactive) spm - ©2014 adolfo villafiorita - introduction to software project management 91 Risk Monitoring and Control a.k.a. Risk Response Planning: how do we take care and exploit risks Risk Monitoring and Control Input: – The risk register Process – Analyze deviations from the nominal plan – Identify causes – Evaluate corrective actions – Modify current plan Mind: – Planned risks must be dealt with as above (use contingency plans) – Unplanned risks require the full process! spm - ©2014 adolfo villafiorita - introduction to software project management 40 Conclusions and The main risks of... Risk Management! Some Common Errors During the Planning Phase: – Not identifying a maximum risk value * Give up a project if too risky – Not writing a balanced risk management plan * Size and complexity have to be at the right level for the project – Misinterpreting effects as causes * You end up caring for the wrong event and not looking at the actual problem * Example 1: We might be late with the project * Example 2: We may be charged 100.000 euros as a penalty spm - ©2014 adolfo villafiorita - introduction to software project management 95 Some Common Errors During Risk Monitoring: – Do not apply contingency plans * Dealing with risk when they occur is more error-prone than think about the strategies before they occur – Do not involve actors * Make sure stakeholders understand consequences of the risk (share the risk) * involve stakeholders in dealing with them – Do not update the plan * Helps keeping the contingency plans really applicable spm - ©2014 adolfo villafiorita - introduction to software project management 96 Project Pricing Goals of the Unit Understanding what are the main factors determining project and project outputs price Learn some strategies to determine price Understanding in more details the procurement process spm - ©2014 adolfo villafiorita - introduction to software project management !2  Initiate Plan Execute & Close Monitor Assess Formalize Collect Close Feasibility Goals Outputs Monitor Goals, Cost and Develop Release Schedule Define Kick Off Schedule Activities Define Costs [Obtain Approval] Change Control & Configuration Management Quality Management Risk Management Human Resource Management Project/Product Lifecycle Business System Operations Divestment Justification Development [ Product Evolution and Upgrade ] Maintenance All phases (including divestment) are a source of cost, investment, or revenue We can quote the project products or the project itself (or both, if you are very lucky) spm - ©2014 adolfo villafiorita - introduction to software project management !4 Pricing Models Software Pricing Three different models to determine software price: – Based on Cost * Based on the production costs * However for some: production costs can be thought as sunk costs (once the system is ready): at a bare minimum, software should cover operating costs – Based on Value * Based on the value perceived by the client * Different factors can be used to change the perceived value: reputation, sentiment, market segmentation (pro/base) – Based on Competition * Based on the price set by the competition spm - ©2014 adolfo villafiorita - introduction to software project management !6 Selling, Licensing, or Leasing Ownership (of source code and executables) is an important factor in determining software price Software is usually licensed (grant to use it), like many other digital assets (e.g. music, books) License granting schema include: – By the copy – In bulk (user, seat, maximum number of instances) Leasing is an alternative schema in which the use of the software is granted for a limited time – Lower price – Protection mechanisms are necessary spm - ©2014 adolfo villafiorita - introduction to software project management !7 Open Source and Free Software Many different licenses: – MIT, Apache, Mozilla, BSD, GNU,... (http://opensource.org/licenses) Characterizations: – Rights: free use, access to source code – Duties: license of modified portions, license of tools built with the open source components Commercial exploitation: – Some licenses allow to build commercial software – Freemium services – Installation, training, documentation, gadgets, donations Commercial exploitation is not the only benefit for an organization (community building, support, advertisement,...) spm - ©2014 adolfo villafiorita - introduction to software project management !8 Project Pricing price = profit + costs [Source: Maylor, Project Management] Similar to software pricing, project pricing has three strategies – Fix the price: pricing to win – Fix the costs: target costing – Fix the profit (percentage on actual costs) spm - ©2014 adolfo villafiorita - introduction to software project management !9 Contractual Agreements Typical Contractual Agreement Client and contractor have opposing goals in setting price and schedule payments Contracts regulate this opposing goals by sharing risks on results and payments E.g.: – Startup: payment upfront (client exposed) – Project execution: contractor exposed – Project delivery: both happy (... or unhappy) Different agreement schema can be used to “negotiate” these different goals spm - ©2014 adolfo villafiorita - introduction to software project management !11 Fixed Price Contract Fixed Price Contract is a kind of agreement where the prices is fixed at the beginning. Considerations: – Accurate estimations are needed – The client might end up paying more (since contingency has to be taken into account) – The supplier might risk losing money – As pointed out in Wysocki (2011), ”all potential suppliers might agree on a fixed price, but this could be a way to just get in the door and work the details later” spm - ©2014 adolfo villafiorita - introduction to software project management !12 Time and Materials Time and Materials is a kind of agreement in which the vendor exposes the costs to the client and bills the client according to the actual costs incurred into. The vendor to track activities and actual time spent in the project. Considerations: – Need to keep formal records of time spent (e.g. time sheets of personnel; actual proof of expenditures - travels,...) – Risk of cost overruns/inefficiency/low productivity – The agreement works well in situations with a high uncertainty or volatility of requirements, since it shares the project risks between the two contracting parties. spm - ©2014 adolfo villafiorita - introduction to software project management !13 Retainer Retainer is a kind of contract in which a fixed price is paid to the vendor in change of a fixed amount of time provided. The fee is paid in advance and the work to performed defined later Considerations: – It is equivalent to renting man-power – Best if requirements are not clear – Reporting necessary – It might be based on a personnel fee lower than in the time and material case (after all, it is paid in advance) – Payments might be split in regular periods (e.g. monthly) spm - ©2014 adolfo villafiorita - introduction to software project management !14 Cost Plus Cost Plus is a kind of agreement in which the buyer pays a contractor for all allowed expenses up to a set limit. An additional payment is foreseen that allows the contractor to make a profit if certain conditions are met. Types of cost plus contracts: – Award-fee contracts, if the additional payment is bound to the final quality of the product – Incentive fee contracts, if the additional payment is bound to contracts that meet or exceed the performances – Fixed-fee contract, if the fee may be adjusted as a result of changes in the work to be performed under the contract. (risky for the vendor - see also considerations about fixed price) Considerations: – It shares project risks between client and supplier – These kind of agreements are applied by Government Agencies – Cost-plus can be used when efficiency, quality, or improved performances are a desirable feature – It make more difficult to control cost overruns. – Additionally, this kind of agreement requires additional book-keeping, e.g. to verify that all the expenditures exposed by the contractor are eligible. spm - ©2014 adolfo villafiorita - introduction to software project management !15 Contractual Agreements and Project Budget Payment schedules need to be regulated to balance risks (financial exposure of the contractor) and commitment (investment before results are delivered) Consider the extreme cases: pay before the project starts; pay after the project ends When reasoning from a purely economical point of view, the cost to finish (and not the sunk costs) determine whether it makes sense to continue a project or not spm - ©2014 adolfo villafiorita - introduction to software project management !16 Typical Payment Structures Based on actual outputs: – Payments based on deliverables: each significant deliverable determines a payment based on the planned cost to produce it Based on time spent: – Payments are performed on a regular basis, based on the actual time spent – It requires maintaining timesheets and receipts/proofs of expenditures – It requires checks and administrative work on both sides Based on project progress: – An advance payment is awarded at project start to cover initial costs and show the client’s commitment – A closing payment is awarded after the project end, to ensure enough time is given to the client to test the system, while retaining the interest of the supplier on the project spm - ©2014 adolfo villafiorita - introduction to software project management !17 Payments and Cash Flow The level of investment of the supplier depends on the payment schema $ Retainer $ Time Billing P1 P2 P3 P1 P2 P3 time time $ By Milestone $ By Milestone with advance payment without advance payment P1 P2 time time P1 P2 P3 spm - ©2014 adolfo villafiorita - introduction to software project management !18 Procurement and Outsourcing The Procurement Process Many projects require procuring services and products from other vendors The process is typically initiated and controller by the project manager with the support of the performing organization According to the performing organization, various constraints can affect the margin of maneuver of the project manager and the timing of activities An appropriate time has to be allocated for procurement activities to complete and sufficient resources to monitor the process spm - ©2014 adolfo villafiorita - introduction to software project management !20 The Procurement Process Identify needs the actual procurement needs are individuated and set. Identify and select vendors: – solicitation, – selection, – awarding Manage contract execution Accept final product this is the phase during which the product is accepted. spm - ©2014 adolfo villafiorita - introduction to software project management !21 Solicitations What can be done depends upon legal and organizational constraints Invitation to tender is publicized and made available in one of these three modalities: – Open tender... everyone is invited to submit and apply – Restricted tender... a selected number of vendors is invited to submit – Direct call... just one Motivations: – Managing the trade-off between costs (open tenders yield more competitive offers), quality (restricted and direct calls might reduce uncertainty over quality), and time (direct call is the fastest) spm - ©2014 adolfo villafiorita - introduction to software project management !22 Invitation to Tender Minimum information set includes: – Specification of the products or services to be provided: a statement of work defining what is the output of the project – Constraints related to the contract, such as timing, quality/ reliability/adherence to standards, required support after the contract ends, management of intellectual property rights. – Modalities to submit the proposal and, in the case of public selections, the selection criteria which will be used to award the contract. spm - ©2014 adolfo villafiorita - introduction to software project management !23 Open Tender Timing Considerations Open and restricted tenders might require a significant amount of time (e.g. months) from idea to actual delivery Consider time for the following activities: – The preparation of the invitation to tender, which defines the requirements (notice that the terms are difficult and costly to change, once the tender is out) – Sufficient time for potential bidder to become aware of the bid and properly respond. For open tenders, the time in Italy is a minimum of 50 days. More time can be taken into account for complex projects – Time to evaluate the proposals received – Time to award the contract – Time for the contractor to actually deliver the products or services agreed upon spm - ©2014 adolfo villafiorita - introduction to software project management !24