Software Project Management: Monitoring and Control

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 

Project control cycle

Responsibility

Project steering committee

Project board

Reporting formal or informal

Assessing progress

Setting checkpoints

Regular

Tied to specific events

Taking snapshots

   Review points or control points

   Assess progress daily

2 Collecting data

Contents

   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

BCWS

Baseline budget

BCWP-budgeted cost of work performed

Technique

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

Definition:

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:

      Strategies

            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.

CHANGE MANAGEMENT:

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

   Bespoke

   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:

   Advantage:

   Known customer expenditure

   Supplier motivation

   Disadvantage

   Higher prices to allow for contingency

   Difficulties in modifying

   Upward pressure on the cost changes

   Thread to system quality

            Time and material contracts

   Advantage:

   Ease of changing requirements

   Lack of price pressure

   Disadvantage:

   Customer liability

   Lack of supplier

            Fixed price per unit delivered contracts:

Fixed price per unit delivered contracts

Advantage:

   Customer understanding

   Comparability

   Emerging functionality

   Supplier efficiency

   Life cycle change

Disadvantage:

   Difficulties with s/w size measurement

   Changing

Based on contractor selection

Open tendering

Restricted

negotiated

11. Stages in contract placement

—  Requirement analysis

   OR

   Mandatory

   Desirable

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:

   Definitions

   Forms of a agreement

   Goods and services to be supplied

   Services to be provided

   Ownership of the software

Acceptance

Acceptance tests

Internal test plans

Pitfalls

Very short warranty period

STAGES  IN  CONTRACT  PLACEMENT  AND  TYPICAL  TERMS  OF  A CONTRACT

Requirements document

     Introduction

     Description of existing system and current environment

     Future strategy or plans

     System requirements -

– Mandatory/desirable features

     Deadlines

– 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

13. CONTRACT MANAGEMENT

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

14 .ACCEPTANCE

     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;

Definitions;

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.