Home | | Software Project Management | Software Project Management: Monitoring and Control

Chapter: Software Project Management

Software Project Management: Monitoring and Control

1 Creating Framework 2 Collecting The Data 3 Visualizing Progress 4 Cost Monitoring 5 Earned Value 6 Prioritizing Monitoring 7 Getting Project Back To Target 8 Change Control 9 Managing Contracts 10 Types Of Contract 11 Stages In Contract Placement 12 Typical Terms Of A Contract 13 Contract Management 14 Acceptance


1 Creating Framework

2 Collecting The Data

3 Visualizing Progress

4 Cost Monitoring

5 Earned Value

6 Prioritizing Monitoring

7 Getting Project Back To Target

8 Change Control

9 Managing Contracts

10 Types Of Contract

11 Stages In Contract Placement

12 Typical Terms Of A Contract

13 Contract Management

14 Acceptance


1. Creating framework 

Project control cycle



Project steering committee


Project board


Reporting formal or informal


Assessing progress


Setting checkpoints




Tied to specific events


Taking snapshots


   Review points or control points


   Assess progress daily



2 Collecting data




   Partial completion reporting


   Risk reporting


Time Sheet:


Activity Assessment Sheet:



3. Visualizing progress:


Gantt chart:


Slip chart


provides visual indication of activities which are not progressing in schedule


Ball charts -Shows whether or not targets have been met



Time lining:


—       Records and displays how the targets have changed throughout the duration of project


4. Cost monitoring:


            Expenditure monitoring


            Framing cumulative expenditure chart


            Projected future costs

Computer-based planning tool


Tracking expenditure


5. Earned value: Earned value analysis


Assigns a value to each task




Baseline budget


BCWP-budgeted cost of work performed




The 0/100 technique


The 50/50 technique


The mile stone technique


The baseline budget


First stage in baseline budget


Forecast growth



Specify overall system


Expenditure chart



Baseline budget calculation


Earned value tracking chart


Performance statistics from earned value chart


Budget variance


Schedule variance


Coast variance


Performance ratios Schedule performance index SPI=BCWP/BCWS


Earned value charts with revised forecasts




Earned value analysis is a method of performance measurement. Earned value integrates cost, schedule and scope and can be used to forecast future performance and project completion dates. It allows projects to be managed better – on time, on budget.


Three quantities form the basis for cost performance measurement using Earned Value Management. They are


        Budgeted Cost of Work Scheduled (BCWS) or Planned Value (PV)


        Budgeted Cost of Work Performed (BCWP) or Earned Value (EV) and


        Actual Cost of Work Performed (ACWP) or Actual Cost (AC).

The above quantities are defined below.


     Budgeted Cost of Work Scheduled (BCWS) or Planned Value (PV)


– The sum of budgets for all work packages scheduled to be accomplished within a given time period.


     Budgeted Cost of Work Performed (BCWP) or Earned Value (EV)


– The sum of budgets for completed work packages and completed portions of open work packages.


     Actual Cost of Work Performed (ACWP) or Actual Cost (AC)


– The actual cost incurred in accomplishing the work performed within a given time period. For equitable comparison, ACWP is only recorded for the work performed to date against tasks for which a BCWP is also reported.


From these three quantities we can determine our total program budget as well as make a determination of schedule and cost performance and provide an estimated cost of the project at its completion. Additional terms are defined to record cost and schedule performance and program budget:


     Schedule Variance (SV)


– The difference between the work actually performed (BCWP) and the work scheduled (BCWS). The schedule variance is calculated in terms of the difference in dollar value between the amount of work that should have been completed in a given time period and the work actually completed.


     Cost Variance (CV)


– The difference between the planned cost of work performed (BCWP) and actual cost incurred for the work (ACWP). This is the actual dollar value by which a project is either overrunning or under running its estimated cost


Two Performance Ratios:


     Cost Performance Index (CPI)


– The ratio of cost of work performed (BCWP) to actual cost (ACWP). CPI of 1.0 implies that the actual cost matches to the estimated cost. CPI greater than 1.0 indicates work is accomplished for less cost than what was planned or budgeted. CPI less than 1.0 indicates the project is facing cost overrun.


     Schedule Performance Index (SPI)



– The ratio of work accomplished (BCWP) versus work planned (BCWS), for a specific time period. SPI indicates the rate at which the project is progressing.


     Estimate at Completion (EAC)


– It is a forecast of most likely total project costs based on project performance and risk quantification. At the start of the project BAC and EAC will be equal. EAC will vary from BAC only when actual costs (ACWP) vary from the planned costs (BCWP).


        Earned Value Management Formula:



6 Prioritizing monitoring


            Critical path activities


            Activities with no free float


            Activities with less than a specified float


            High risk activities


            Activities using critical resources



7 Getting the project back to target:




            Shortening the critical path


            Altering the activity precedence requirements



Shorten critical path


Speed up non-critical path activities


Fact finding


Time/cost trade off


Reconsider the precedence requirements


            Normal working practices


            Subdivide to components


            Assess changes



8 Change control:


            A change in program specification


            Change program design and then code


Change control procedures


The role of configuration librarian:


Identifying items that need to be subject to change control


Management of a central repository of the master copies of software and documentation


Administering change procedure.


Maintenance of access records


Typical change control process


One or more users might perceive the need for a change


User management decide that the change is valid and worthwhile and pass it to development management


A developer is assigned to assess the practicality and cost of making the change


Development management report back to user management on the cost of the change; user management decide whether to go ahead


One or more developers are authorized to make copies of components to be modified


Copies modified. After initial testing, a test version might be released to users for acceptance testing .


When users are satisfied then operational release authorized – master configuration items updated .



Change control and configuration management


     Change control


– Set of procedures to ensure that changes made only after a consideration of the full impacts.


     Configuration management


– Version control to ensure that all changes are properly recorded and managed – and so that knock-on effects on other projects can be identified.



9. Managing contracts:


Contract administration is the management of contracts made with customers, vendors, partners, or employees.The personnel involved in Contract Administration required to negotiate, support and manage effective contracts are expensive to train and retain. Contract management includes negotiating the terms and conditions in contracts and ensuring compliance with the terms and conditions, as well as documenting and agreeing on any changes or amendments that may arise during its implementation or execution. It can be summarized as the process of systematically and efficiently managing contract creation, execution, and analysis for the purpose of maximizing financial and operational performance and minimizing risk.




There may be occasions where what is agreed in a contract needs to be changed later on. A number of bases may be used to support a subsequent change, so that the whole contract remains enforceable under the new arrangement.


A change may be based on:


           A mutual agreement of both parties to vary the contract, outside the framework of the existing contract. This would be an independent basis for changing the contract.


           A unilateral decision to vary the contract, contemplated and allowed for by the existing contract. This would normally have notice periods for fairness and often the right of the other, especially in consumer contracts, to cease the contractual relationship. Be careful that any one-way imposition of change is contractually justified, otherwise it may be interpreted as a repudiation of the original contract, enabling the other party to terminate the contract and seek damages.


           A bilateral decision to vary the contracting, within the variation or change control process outlined in the existing contract. These are often called change control provisions.


10 Types of contract


   Completed software application




   Off-the shelf



   Customized off-the shelf


   Payment calculation


   Fixed price contracts


   Time and material contracts


   Fixed price per delivered unit contracts


            Fixed price contracts:




   Known customer expenditure


   Supplier motivation




   Higher prices to allow for contingency


   Difficulties in modifying


   Upward pressure on the cost changes


   Thread to system quality


            Time and material contracts




   Ease of changing requirements


   Lack of price pressure




   Customer liability


   Lack of supplier


            Fixed price per unit delivered contracts:




Fixed price per unit delivered contracts




   Customer understanding




   Emerging functionality


   Supplier efficiency


   Life cycle change




   Difficulties with s/w size measurement




Based on contractor selection


Open tendering








11. Stages in contract placement


—  Requirement analysis









Sections in requirement document:



Evaluation plan:


   Draw up plan account to proposals


   Opposed to off the shelf application


   Mandatory requirements are identified


   Value for money



            12. Typical terms of a contract:




   Forms of a agreement


   Goods and services to be supplied


   Services to be provided


   Ownership of the software




Acceptance tests


Internal test plans




Very short warranty period





Requirements document




     Description of existing system and current environment


     Future strategy or plans

     System requirements -


– Mandatory/desirable features



– Functions in software, with necessary inputs and outputs

– Standards to be adhered to

– Other applications with which software is to be compatible

– Quality requirements e.g. response times

     Additional information required from bidders


Evaluation plan


     How are proposals to be evaluated?

     Methods could include:


– reading proposals



– Interviews


– Demonstrations

– Site visits

– Practical tests


Invitation to tender (ITT)


     Note that bidder is making an offer in response to ITT

     Acceptance of offer creates a contract

     Customer may need further information

     Problem of different technical solutions to the same problem


Memoranda of agreement (MoA)


     Customer asks for technical proposals

     Technical proposals are examined and discussed

     Agreed technical solution in MoA

     Tenders are then requested from suppliers based in MoA

     Tenders judged on price

     Fee could be paid for technical proposals by customer





Contracts should include agreement about how customer/supplier relationship is to be managed e.g.


– Decision points - could be linked to payment


– Quality reviews

– Changes to requirements





     When work is completed, customer needs to carry out acceptance testing.

      Contract may put a time limit to acceptance testing – customer must perform testing bf

time expired.

• Part or all payment to the supplier should depend on acceptance testing

Acceptance criteria are defined as “the list of requirements that must be satisfied prior to the customer accepting delivery of the product”.


This document defines the acceptance process, the acceptance criteria, and the review/approval required for customer acceptance of the (Agency name) (project name) project deliverables.


The purpose of this document is to define a standardized Deliverable Review Process, which will provide a structured method to support the Agency Software Verification and Validation Plan (SVVP) to ensure that appropriate, correct, consistent, and complete deliverables are created for the project.

This document describes:


Goals of the review process;



Meeting participants, roles, and responsibilities;

Review process;

Dispositions for the review meeting; and

Review exit criteria.



The primary goal of the Deliverable Review Process is to detect and remove deliverable defects as early as possible in the Software Development Life Cycle (SDLC) process.


Secondary goals to be attained are:


Consistency with IEEE Std 1028-1997, Standard for Software Reviews;


Ensure correctness, completeness, consistency, and accuracy of deliverables and products for all life cycle activities within the development process;


Acceptance Process for Project Deliverables


The acceptance process for (Project Name) provides a roadmap for incremental acceptance by the customer of the software application and associated project deliverables at the following key milestones.


Project Phase Concept Complete

Phase Requirements Complete

Phase Design Complete

Phase Application Ready For Pilot


Phase Application Ready For Statewide Rollout

Phase Complete

Acceptance Criteria for Milestones and Deliverables


The acceptance criteria in the table below define the conditions under which the PROJECT Business Sponsor(s), the PROJECT IS Sponsor, and the Project Manager agree that they will accept completion of the milestones and deliverables subject to these acceptance criteria.

Study Material, Lecturing Notes, Assignment, Reference, Wiki description explanation, brief detail
Software Project Management : Software Project Management: Monitoring and Control |

Privacy Policy, Terms and Conditions, DMCA Policy and Compliant

Copyright © 2018-2024 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.