Project Management and Control

Syllabus : Framework for Management and control – Collection of data Project

termination – Visualizing progress – Cost monitoring – Earned Value Analysis-
Project tracking – Change control- Software Configuration Management –
Managing contracts – Contract Management.

Section No. Topic Name Page No.

4.1 Project Tracking and Monitoring 4-2
4.2 Monitoring the Progress 4 - 10
4.3 Cost Monitoring 4 - 14
4.4 Earned Value Analysis or Earned Value 4 - 15
Management (Cost Monitoring Technique)
4.5 Change Control 4 - 20
4.6 Software Configuration Management 4 - 22
4.7 Managing Contract and Contract Management 4 - 30
4.8 Project Monitoring and Controlling Process in Detail 4 - 40
4.9 University Questions with Answers 4 - 44

4-1 Software Project Management

 Project Management and Control

4.1 Project Tracking and Monitoring

 Make sure the project

o Can be delivered on time and within budget
o Is of good quality
o Meets client’s needs
In fact, the project manager has to make sure everything goes well in the project.
4.1.1 What Can Go Wrong in Product ?

 Inadequate functionality of a product.

o Related to software requirements specification
 Poor quality of a product.
o Related to quality management
 Late delivery of the product.
 Overly exceeding the budget.
 SRS : Software Requirements Specification.
 In fact, many things can go wrong. Normally, these are the major things. The ordering
does not indicate their relative order of importance.
 Inadequate functionality is related to SRS.
 Poor quality is related to quality management.
 These two are discussed in previous lectures.
 Our concentration is on the latter two.
4.1.2 Planning, Tracking and Monitoring

 Planning
o Know where we want to go
 Tracking
o Know where we are
 Monitoring
o How to go from where we are to where we want to go

4-2 Software Project Management

 Project Management and Control

Tracking

 Finding out what is happening

 Need a plan and schedule
 To collect data
 Ideally, the plan and schedule should be absolutely clear and highly visible to every
personnel involved in the project.
Monitoring

 Comparing the current status with the targets

 Need a plan, a schedule, collected data
 To exercise control over the project
 To ensure the targets are met
 To devise contingency plans
4.1.3 Creating Framework for (Monitoring and Control)
4.1.3.1 Creating Framework

 Exercising control over a project and ensuring that targets are met is a matter of regular
monitoring.
 Finding out what is happening and comparing it with current targets.
 The projects starts its execution, the project must be carefully monitored to ensure the
project’s progress.
 Expected outcomes are compared with the actual ones.
 Project control is a continuous process of monitoring the progress of the project plan
and is also includes re-planning of activities.
Revising the planning strategy is due to,

 Delay in completion of the project within the target time

 Quality factors
 Inadequate functionality in adopting newer techniques
 Actual estimation

4-3 Software Project Management

 Project Management and Control

Fig. 4.1.1 The project control cycle

4.1.3.2 Responsibility

 The overall responsibility for ensuring satisfactory progress on a project is often the
role of the project steering committee or project board.
 Categories of reporting are classified as,
Formal and Informal.
 Formal regular types can be oral or written.
 Standard oral communication of minutes are kept where as written type gets the
reporting issues in a separate written format.
 Formal ad hoc are mostly received information of different levels towards the end of
the project and generate written reports.
 Informal, oral and ad hoc provides early warning to the system and must be backed up
by formal reporting procedures.

4-4 Software Project Management

 Project Management and Control

Fig. 4.1.2 Project reporting structures

 Single activity will not yield a deliverable work product but a group of activities can
achieve the specified tangible product.
 The development of the project measures the progress assessment.
 It is carried out by the team members who are associated with the project activities.
4.1.4 Tracking the Performance

 Tracking performance means assessing the progress

o Need to trust your personnel to give an objective assessment of their work and their
estimation on completion of their work
 Setting check points
 Collecting data
4.1.4.1 Check Point

 Based on regular time intervals

o Can be weekly or monthly or quarterly
o Depend on what to check and how to
 Based on a particular event
o At the end of each activity
o In the middle of a critical activity
Time interval : Duration actually depends on who to check, what to check, the degree
of risk of the project; how familiar the new employee is to the process of the
organization.

4-5 Software Project Management

 Project Management and Control

Critical activity : The number of check points depends on how critical the event is.
 Tied to specific events such as the production of a report.
 Should be set before the plan was published
o Make sure everyone knows when and what the check points are
4.1.4.2 Collecting Data

 Need to collect data to review the progress of a project.

 It is crucial to know what to collect and how.
 As a manager, it is wise to break down activities that can be completed in one or two
weeks time.
 These reports are filled on a weekly basis.
 Collect Partial completion report.
 Collect Risk report.
1. Partial completion report

 Indicate the work done by the personnel and the time spent on the work
 Optional items
o likelihood of failing to complete the task by the scheduled date
o Estimated time of completion
 For the optional items, there are advantages and disadvantages.
 Advantages :
o Staff involvement
o Get the latest first hand information from the staff
o Have a better picture on what is going on
 Disadvantages :
o Make the personnel have wrong feelings that
 the original schedule not so important; and
 it is OK for the task to be delayed.
 Background information on time-sheet for accounting system :
o The time spent is used by the accounting system to charge the project account.
o A way to keep track of the cost on the project.

4-6 Software Project Management

 Project Management and Control

Partial completion report – Example

Time Sheet
Staff : Paul Week ending : 14/5/99
Rechargeable hours
Project Act. code Description Hours % done Sch. Date Est. date
P20 A267 Code mod A7 24 90 01/06/99 20/05/99
P35 B397 Testing mod B8 12 30 24/06/99 24/06/99
Total 36
Non-rechargeable hours
Code Description Hours Comments and Authorization
L90 hours in Lieu 4 Authorized by Peter
Total 4
2. Risk reporting
 Indicate the likelihood of meeting the scheduled target date
o Instead of asking the estimated completion date
 Use the traffic-light method
o Steps are,
 Identify the first level elements for assessment.
 Break the first level elements in to second level elements.
 Asses the second level elements and mark the colors.
The traffic-light method
For assessing a product
 Identify the key (first-level) elements
 Break them into smaller components
 Assess each component by
o Green as ‘on target’
o Amber as ‘not on target but recoverable’
o Red as ‘not on target and recoverable only with difficulty’
 Assess the key-level element based on the assessments of their components
 Assess the overall product based on all the assessments (key elements and their
components)

4-7 Software Project Management

 Project Management and Control

 Review all second level elements to reach the first level assessments.
 Review both first and the second level assessments to produce an overall
assessments.
 Focus on non achievement factors.
 Assessment forms can be used to evaluate the overall status of the project.
 Critical activities denoted by red color.
 Critical activity : activity that cannot be delayed.
 Float : time allowed for an activity to be delay.
 Managers should play attention to the following events :
1. Critical activities classified as Amber or Red
2. Non-Critical activities classified as Red, especially when all their float is
likely to be consumed.
The traffic-light method - Example

Activity Assessment Sheet

Staff : Zobel
Ref : IoE/P/100 Activity : Code and test module A
Week number 13 14 15 16
Activity summary G A R
Component Comments
Screen handling procedures G G A
File updating G A R
Compilation G G A
Run test data G A A

4.1.5. Prioritizing Monitoring (Level of Monitoring)

 Priority list of activity to monitor

o Critical activities
o Non-critical activities with no free float
o Non-critical activities with less than a specified float
o High risk activities
o Activities with critical resources

4-8 Software Project Management

 Project Management and Control

 Need to spend your energy wisely.

o Free float : The time allowed for an activity to delay without affecting any
subsequent activity
o Total float : The time allowed for an activity to delay without affecting the overall
project
 High risk activities : Activities having a high estimated duration variance (PERT)
o They are most likely to overrun or overspend.
 Activities with critical resources : activities that require a huge amount of resources
require much more attention.
o The reason is obvious. MONEY.
4.1.6 Bringing the Project back to Target

 You are now behind the schedule

 Possible actions :
o Reschedule the target date
o Reschedule other activities with shorter duration
o Reorder the activities
 Reschedule the target date :
o Re-estimate the rest of the project and get a proper target date
o This means delaying the delivery date
o This is, in general, a bad choice.
o It is because this costs money and your company loses the customers (unless your
product is too poor to delivery).
 Reschedule other activities with shorter duration :
o Non-critical activity has float.
o Effectively it means shorter time for the critical activity.
 Reorder the activities
o Sometimes, it is possible to reorder the activities so that the overall duration for the
activities to complete can be shorten.
o This involves the consideration of the precedence requirements for the activities.
4.1.6.1 Shorten the Critical Activities

 Putting pressure on the personnel

 Increasing the resources

4-9 Software Project Management

 Project Management and Control

o Personnel work longer hours.

o Additional analysts to interview users.
o Competent programmer to code modules in the critical activity.
 Pressure :
o May work for some time.
o People work under high pressure may cost more error.
 Resources :
o Employing new personnel in the team (?) Arguable.
 Shortening a critical path may result in a new critical path.
 Better to check the newly revised schedule again.
4.1.6.2 Reorder the Activities
 Relax the constraints on the start of an activity before the completion of the previous
one.
 Subdivide the components of an activity so that they can be done in parallel.
 The most important of all is to check that the quality of the product is not sacrificed.
 It is because the ‘normal’ practice is disturbed by the changes.
 Relaxing constraints : Example
o Ideal to start user training after acceptance testing.
o In order to avoid late delivery, it might be possible to let the two activities have
some overlap.
o For example, you may want to start the training of a particular feature once its
system testing is completed.
 Subdivide activity :
o Documentation of user manual and training manual.
4.1.7 Acceptance

 Customer has to undergo acceptance testing towards the end of the process.
 Every contract would have defined a time limit for the acceptance testing and the result
has to be produced before the time expires.
 All the payment to the supplier depends on the acceptance testing.
 Every bug that is raised must be fixed within the period of warranty.

4.2 Monitoring the Progress

 Need to monitor time : Visualizing the progress

 Need to monitor cost : Earned Value Analysis

4 - 10 Software Project Management

 Project Management and Control

4.2.1 Visualizing Progress

 A manager needs some way of presenting that data to greatest effect.

 Presenting the collected data in a way that is easy to understand.
 Help to easily identify the problem activities or areas that need to be taken care of
 Some methods of presenting picture are,
1. Gantt chart – tracking project progress.
 A static picture showing the current progress of the project.
 It is the simple and the oldest form of representing the progress of the project.
 It consists of activity bar that indicates the scheduled activity dates and the
duration along with the activity floats.
 The reported progress is normally shaded.
 The ‘today cursor’ is used to show which activities are ahead or behind the
schedule.
Advantage : Simple and easy to use.
Disadvantage : Difficult to update manually
 It is because the chart needs to be redrawn once the schedule has been revised.

Fig. 4.2.1

4 - 11 Software Project Management

 Project Management and Control

2. Slip chart –Add a slip line on the Gantt chart.

 An alternative view of Gantt chart by providing a visual indication of those
activities which are not on schedule.
 The slip line indicates those activities that are either ahead or behind the schedule
 The more bending is on the slip line, the greater is the variation of the plan.
 Too much bending indicates a need for rescheduling of the overall plan
 If the slip line deviates more towards the non achievement of project objectives
then it has to be reconsidered.
 Additional slip lines can be included at regular intervals.

Fig. 4.2.2
3. Ball charts – way of showing or not targets have been met or not.
 It is represented in the form of circles that indicate the start and the end point
completion of activities.
 Circles of the ball chart mostly contain only two dates the original and the revised
one.
 An activity is denoted by a red circle and green color denotes that the activity is
ahead of its schedule.
 Slippage in the project completion date but it is overcome by the timeline charts.

4 - 12 Software Project Management

 Project Management and Control

Fig. 4.2.3 Ball chart provides an incentive for meeting targets

4. The Timeline
 A dynamic picture showing the progress of the project and how the project has
changed through time
 A plot of the elapsed time against the planned time of the activities indicating
o the actual progress of the activities; and
o the rescheduled activities by the end of each week
 Show where and when the targets have changed through the life of a project.
 A perfect straight line down to the diagonal line indicates the activity is on the
schedule.
o Need to be selective.
o Do not put too many activities in the same Timeline.
o Otherwise it will be difficult to trace.
 Recommendation :
1. Put only those critical activities on the Timeline.
2. Put those non-critical activities that have a very short float.

4 - 13 Software Project Management

 Project Management and Control

Fig. 4.2.4 Timeline chart at week 7

 Can show the slippage of the activities through the life of the project
o The Gantt chart cannot
 Help to analyze and understand the trends and reason for changes
o to avoid slippage in future projects
 Analyzing the timeline and the reason for changes may help to identify failures in
estimations.
 The Timeline cannot show when an activity starts

4.3 Cost Monitoring

 It is an important component of project control. Not only in itself, but also because it
provides an indication of the effort that has gone into (or at least been charged to) a
project.
 It provides a simple method of comparing actual and planned expenditure.
 The more cost is incurred to complete the activities to keep the project on
schedule.
 The chart does a comparison between the actual and the planned expenditure.
 Cost charts become much more useful if we add projected future costs calculated by
adding the estimated costs of uncompleted work to the costs already incurred.

4 - 14 Software Project Management

 Project Management and Control

 Where a computer-based planning tool is used, revision of cost schedules is generally

provided automatically once actual expenditure has been recorded.

Fig. 4.3.1 Cumulative cost chart

4.4 Earned Value Analysis or Earned Value

Management (Cost Monitoring Technique)

 Simply, it is a project monitoring and measurement system that :

1. Establishes a clear relationship between planned accomplishments and actual
accomplishments
2. Reinforces and rewards good planning practices
 Basic concepts of Earned Value Management (EVM)
1. Each task in a project earns value as planned work is completed
2. Earned value can be compared to actual cost and budgeted cost to determine
variance and predict future performance
 The budgeted cost (e.g., dollars, person-hours, person-days, etc.) in terms of your
baseline plan/budget of the work performed up to a specified point in time
1. Also known as Budgeted Cost of Work Performed (BCWP)
 Each task in the Work Breakdown Structure (WBS) is assigned a BCWP based on its
individual cost.
1. Project BCWP is total of BCWP for all tasks required to complete the project

4 - 15 Software Project Management

 Project Management and Control

Fig. 4.4.1

Earned Value Indicators

 Planned Value (a.k.a. BCWS)
1. How much work (person-hours) you planned to have accomplished at a given
point in time (this is from the WBS in your plan)
 Actual Cost (a.k.a. ACWP)
1. How much work (person-hours) you have actually spent at a given point in time
 Earned Value (a.k.a. BCWP)
1. The value (person-hours) in terms of your base budget of what you have
accomplished at a given point in time (or, % complete X Planned Value)

4.5 Change Control

4.5.1 Some Basics

“Change Control” is a formal process. It is set up to enable project teams to modify the
scope of the project using specified controls and policies. Change can include anything that
would impact the project time, budget, scope, all of which can impact quality. Most of the
time, it’s scope that impacts the other items.
4.5.2 Change Control Process
1. Define the Change Request

Change Control is the process. A Change Request is the documentation used to request
the actual change. Whoever owns the actual request needs to explain it in such a way that the
team understands it well enough to define it. This should be done through appropriate
documentation (whatever the project team or company expects). It can be as simple as an
email or as complex as a formal document.
When defining the change, it’s necessary to have in hand the actual request with all
supporting statements. This should include :
 Actual Request : Statement of the need. This should outline clearly the change item
for the project team to analyze.
 Reason for the Request : Customer impacts if the request cannot be completed or if
considerable time passes before the request can be completed
 Conditions of Success : Customers must be able to define what they expect from the
change.
 Expected Completion : The requester should provide an expected due date for the
4 - 16 Software Project Management
 Project Management and Control
item. This doesn’t mean the change will be completed by this date. It’s simply meant to
provide more details for the team to analyze when defining options.
 Expected Value : This should explain why the request is needed. It can either be
something as simple as “better customer experience” or “revised calculation provides
more accurate data” in relation to a report.
2. Submit and Review the Change Request

Once the Change Request is documented, it’s submitted to the project team. Here again,
the process varies from the simple (a phone call or email) to the formal (a memo or meeting).

Unless the request is very simple, It is preferable to review the change with the full team. That
meeting provides the proper venue for the request to be reviewed, and all members have a
chance to ask questions and help make decisions.
There should be two portions to reviewing the Change Request: the formal presentation
or meeting and the project team’s review and discussion of impacts. Within the change control
process there should be an expected turnaround time for these. Discussions with the customer
should include setting expectations regarding response time, or at least when the team will
provide feedback.
3. Define Options and Create Response Document

Once the team has reviewed the Change Request, options should be defined. There
should be a minimum of two. When providing the document response, always provide each
option with some of the data points below as well as a team recommendation, which
represents its view of the best choice. The customer may not always go along, but it can help
them make a decision.
The response should include :
 Option Number and Name
 Proposed Solution : This should include how to respond to the change request. It can
be anything from a technical direction and justification as to why this particular
approach is being put forward.
 Proposed Timeline : The customer always needs to know how long something is
going to take. The estimated timeline is a piece of information they will leverage when
making a choice based on the options the team presents.
 Impacts to the Project : This is an essential part of the response. If changes are small,
there may be no impacts - for instance, if you’re changing a series of messages or
buttons. But most changes will have some sort of impact. The scope change can impact
the timeline, the budget and therefore the quality of the product. This area should
minimally explain the cost of the changes, the impact on the timeline and potential

4 - 17 Software Project Management

 Project Management and Control
quality results. There may also be resource impacts. The team may either have to get
additional people or may define a need for existing resources to add or remove time on
the project. All of these items should be defined clearly to enable the customer’s
decision making.
 Expiration Date for Proposed Changes : This sets a timeframe for the client to
respond to the proposed solution and cost/time impacts. If the client goes outside of the
set window, there could be additional impacts to the project. That aside, setting an
expiration date provides urgency to the process.

4. Final Decision and Approval

The customer should provide a timely response. If the Change Control Response
document expires, it should be re-evaluated once the customer provides feedback. If too much
development has occurred to sustain the change, then that needs to be stated. If the delayed
response has resulted in other impacts, they need to be communicated as soon as possible. It’s
also possible that an expired response could lead to an additional review and proposal.
Whatever decision results from all this needs to be officially approved. When you
define the Change Control process, be sure to include a list of sponsors, stakeholders and key
decision makers who can OK both the process and the decision.
Every change control request should follow this process. This isn’t to simply cover the
team. It provides consistency and manages expectations.

4.6 Software Configuration Management

 “SCM is the control of the evolution of complex systems,…, for the purpose to
contribute to satisfying quality and delay constraints.”
 “SCM provides the capabilities of identification, control, status accounting, audit and
review, manufacture, process management, and teamwork.”
 SCM is a key process in Capability Maturity Model (recently updated to CMMI)
o Level 1-Initial : ad hoc/chaotic
o Level 2-Repeatable : basic project management and documentation
o Level 3-Defined : standard and complete process control and procedures
o Level 4-Managed : predictable process performance and precise measurements
o Level 5-Optimizing : continuous and recursive improvement to performance
 SCM operates through the software life cycle.
4.6.1 What is SCM not ?

 Not just version control

4 - 18 Software Project Management
 Project Management and Control
 Not just for source code management
 Not only for development phase
 Selecting and using tools are important, but design and management of SCM process
are more crucial for project success

Some Simple SCM Scenarios

 A lives in New Dehli, India and B lives in Boston, US, they want to work on
HelloWorld.java together
 In the latest release, a serious bug is found and manager C wants to track what changes
caused the bug, who made those changes and when
 C wants to get reports about current project progress to decide if she needs to hire more
programmers and delay the alpha release
4.6.2 SCM Terminology

 Configuration Item (CI)

 Version, Variant, and Revision
 Configuration
 Baseline
 Workspace
4.6.2.1 Configuration Item (CI)

 An approved and accepted deliverable, changes have to be made through formal

procedure
 Examples :
o Management plan
o Requirement
o Design specification
o Source code and executable code
o Test specification, data, and records
o Log information
o User documentation
o Library and supporting software
o Bug reports, etc.
4.6.2.2 Version, Variant and Revision

 Version : A CI at one point in its development, includes revision and variant

4 - 19 Software Project Management

 Project Management and Control
 Revision : A CI linked to another via revision-of relationship, and ordered in time

 Variant : Functionally equivalent versions, but designed for different settings, e.g.
hardware and software
 Branch : A sequence of versions in the time line

How Versions are Stored

 Full copy of each version
 Delta (differences between two versions)
 Forward delta

 Reverse delta

 Mixed delta
4.6.2.3 Configuration

 An arrangement of functional CIs according to their nature, version and other

characteristics
 Guaranteed to recreate configurations with quality and functional assurance
 Sometimes, configuration needs to record environment details, e.g. compiler version,
library version, hardware platform, etc.
 Simple examples
o Ant buildfile, Makefile
4.6.2.4 Baseline

 A collection of item versions that have been formally reviewed and agreed on, a version
of configuration
 Marks milestones and serves as basis for further development

4 - 20 Software Project Management

 Project Management and Control
 Can only be changed via formal change management process
 Baseline + change sets to create new baselines
4.6.2.5 Workspace

 An isolated environment where a developer can work (edit, change, compile, test)
without interfering other developers
 Examples
o Local directory under version control
o Private workspace on the server
 Common Operations
o Import : put resources into version control in repository
o Update : get latest version on the default branch
o Checkout : get a version into workspace
o Checkin : commit changes to the repository
4.6.3 SCM Processes

 Change control process

 Status accounting
 Configuration audit
 Release management
 CM planning
4.6.3.1 Change Control Process

 Submission of Change Request (CR)

 Technical and business evaluation and impact analysis
 Approval by Change Control Board (CCB)
 Engineering Change Order (ECO) is generated stating
o changes to be made
o criteria for reviewing the changed CI
 CI’s checked out
 Changes made and reviewed
 CI’s checked in
4.6.3.2 Status Accounting

 Administrative tracking and reporting of CIs in CM system.

 Examples

4 - 21 Software Project Management

 Project Management and Control
o Status of proposed changes.
o Status of approved changes.
o Progress of current version, on or behind schedule.
o Estimate of resources to finish one task.
o Bugs identified by configuration audit.
4.6.3.3 Configuration Audit

 Independent review or examination to assess if a product or process is in compliance

with specification, standards, contractual agreement, or other criteria
 Examples
o Verifies that CIs are tested to satisfy functional requirements.
o Verifies that baseline contains necessary and correct CI versions.

o Ensures that changes made to a baseline comply with the configuration status
reports
4.6.3.4 Release Management

 Creation and availability of a new version of software to the public

 Release format
o Source code + build script + instructions
o Executables packaged for specific platforms
o Other portable formats: Java Web Start, plugins
o Patches and updates: automatic, manual
 Release content
o Source and/or binary, data files, installation scripts, libraries, user and/or developer
documentation, feedback programs, etc.
4.6.3.5 Make a CM Plan

 Standards
o IEEE Std 828 (SCM Plans), ANSI-IEEE Std 1042 (SCM), etc.
 CM plan components
o What will be managed (list and organize CIs)
o Who will be responsible for what activities (roles and tasks)
o How to make it happen (design processes for change requests, task dispatching,
monitoring, testing, release, etc.)
o What records to keep (logs, notes, configurations, changes, etc.)

4 - 22 Software Project Management

 Project Management and Control
o What resources and how many (tools, money, manpower, etc.)
o What metrics to measure progress and success

4.6.4 CM Tools

 Version control
o RCS, CVS, Subversion, Visual Source Safe, Rational ClearCase
 Bug tracking
o Bugzilla, Mantis Bugtracker, Rational ClearQuest
 Build
o GNU Make and many variants, Ant

 Project management
o Sourceforge.net, freshmeat.net, GForge, DForge

4.7 Managing Contract and Contract Management

4.7.1 Introduction

Usually, there are two or more different legal entities or parties involved in the project,
normally in customer / contractor or contractor / sub-supplier relationships. These different
parties need to sign a contract before starting implementation phase of a project.
In larger projects with a customer / contractor relationship, on the side of the contractor,
a proposal team will own the project management process in definition and planning phase
until the contract is signed. Then, they will hand over to an implementation team. So, in the
first two phases, a proposal manager is in charge who transfers the project responsibility to a
project manager for implementation and closure phase.
4.7.2 What is a Software Contract ?

A Software contract is any agreement between two or more parties where one party
agrees to provide certain deliveries or services, and the other party agrees to pay for those
deliveries or services.
How do we get a contract between two parties ?

sometimes, It is too easy.

4 - 23 Software Project Management

 Project Management and Control
Fig. 4.7.1

In extreme cases, it just takes an offer by a company and the simple acceptance of that
offer by the customer, and we have a contract. Typically, we will see some negotiation going
on between the two parties before one of them accepts the last offer of the other party.
However, since it is so easy to end up in a legally binding contract situation, the first step,
generally the offer by the company has to be prepared very carefully. Even for smaller
projects we usually need more than two parties to contribute.

4.7.2.1 Software Contract Modes

 Bespoke development : Kind of system is developed for an individual that is created

from scratch.
o In house development
o Contracted (outsourced)
o exactly meets the need of the customer
o requires a dedicated, well balanced knowledgeable team of people with resources.
o Takes time ( resources may not remain)
 Off the shelf : Denotes what the user buys as it as and called as shrink wrapped
software
o Packages - Ms Word, Ms Excel, Tally etc.
o To be bought and used as it is.
o No functionality and/or interface is modifiable.
o functions available, they are well tested and proven at multiple customer sites ( SW
quality high)
o Best Int’l standards followed
o No time loss
o Specific needs of a customer cannot be met
 COTS – customized off-the-shelf : Represents a basic core system that is modified
based on the requirements of the client.
o Combination of the above
o Better than ‘off the shelf’ and falls short of ‘Bespoke’ development.
4.7.3 Types of Software Contracts

There are three basic types of contracts :

1. Fixed Price Contracts :
 These are also known as Lump Sum contracts.
4 - 24 Software Project Management
 Project Management and Control
 The seller and the buyer agree on a fixed price for the project.
 The seller is bound to accept high risk in this type of contract. The buyer is in the least
risk category as the price is already fixed and the seller has agreed to this.
 There must be fully detailed specifications, checklists, project scope statements from
the seller side which the buyer will use.

 Often, sellers may try to cut the scope to deliver the projects on time and within budget.
If the project is finished on time with the desired quality, the project is over for that
contract. However, if the project is delayed and there are cost overruns, then the seller
will absorb all the extra costs.
 Fixed price contracts are typically used in government based projects.
 Advantages of fixed price contracts include :
o Minimizing risk for buyers.
o Known customer expenditure
o Supplier motivation
 The major disadvantage of Fixed Price Contracts is that
o The seller starts cutting scope in order to finish on time and within budget.
o Higher prices to allow for contingency
o Difficulties in modifying requirements
o Upward pressure on the cost of changes
o Threat to system quality
Below are a few types of fixed contracts :
 Fixed Price Incentive Fee (FPIF) – If project ends sooner, an additional amount is
paid to the seller.
 Fixed Price Award Fee (FPAF) – If the performance of the seller exceeds
expectations, an additional amount (say 10% of the total price) will be paid to the
seller.
 Fixed Price Economic Price Adjustment (FPEPA) – The fixed price can be re-
determined depending on the market pricing rate.
2. Cost Reimbursable Contracts :

 What you will do when the scope of the work is not clear? Fixed price contracts
would be out of the question since you are not sure what you need out of the project. In
such cases, ideally you would need to opt for cost reimbursable contracts.
 Under a cost reimbursable contract, the seller will work for a fixed time period, and
will raise the bill after finishing work.

4 - 25 Software Project Management

 Project Management and Control
 A major drawback of this type of contract is that the seller can raise an unlimited or
unknown amount which the buyer is compelled to pay. This is why cost reimbursable
contracts are rarely used.

Below are a few types of cost reimbursable contracts :

 Cost Plus Fee (CPF) or Cost Plus Percentage of Costs (CPPC) – The seller will get
the total cost they incurred on the projects plus a percentage of fee over cost. Always
beneficial for the seller.
 Cost Plus Fixed Fee (CPFF) – A fixed amount (for seller) is agreed upon before work
commences. Cost incurred on the project is reimbursed on top of this.
 Cost Plus Incentive Fee (CPIF) – A performance-based extra amount will be paid to
the seller over and above the actual cost they have incurred on the projects.
 Cost Plus Award Fee (CPAF) – The seller will get a bonus amount plus the actual cost
incurred on the projects. Very similar to a CPIF contract.
3. Time and Material Contracts or Unit Price Contracts :
 Unit price contracts are what we call an hourly rate.
 For example, if the seller spends 1,200 hours on a project, and his or her charges are
$100 an hour, the seller will be paid for $120,000 by the buyer.
 This type of contract is typical in freelance work.
 The main advantage of this type of contract is that the seller will make money for
every hour he spends on the project.

4.7.4 Typical Terms of a Contract

Definitions

The terminology used in the contract document may need to be defined, for example,
who is meant by the words 'client' and 'supplier'.

Form of agreement

For example, is it a contact of sale, a lease, or a licence ? Also, can the subject of the
contract, such as a licence to use a software application, be transferred to another party ?
Goods and services to be supplied

Equipment and software to be supplied This includes an actual list of the individual
pieces of equipment to be delivered, complete with the specific model numbers.
Services to be provided This covers such things as :
 documentation;
 installation;
4 - 26 Software Project Management
 Project Management and Control
 conversion of existing files;
 maintenance agreements;
 transitional insurance arrangements.
Environment

Where physical equipment is to be installed, the demarcation line between the supplier's
and customer's responsibilities with regard to such matters as accommodation and electrical
supply needs to be specified. Where software is being supplied, the compatibility of the
software with the existing hardware and operating system platforms would need to be
confirmed.
Customer commitments

Even when work is carried out by external contractors, a development project still needs
the participation of the customer. The customer will have to provide accommodation for the
suppliers and perhaps other facilities such as telephone lines.
Acceptance procedures

Good practice would be to accept a delivered system only after it has undergone user
acceptance tests. This part of the contract would specify such details as the time that the
customer will have to conduct the tests, deliverables upon which the acceptance tests depend
and the procedure for signing off the testing as completed.
Standards

This covers the standards with which the goods and services should comply. For
example, a customer can require the supplier to conform to the ISO 12207 standard relating to
the software life cycle and its documentation (or, more likely, a customized sub-set of the
standard). Within the European Union, government customers with contracts for projects
above a certain threshold value must, by law, ensure that the work conforms to certain
standards.
Some customers find that specially written or modified software is not thoroughly
tested by the supplier before delivery. Some suppliers seem to think that it is cheaper to get
the customer to do the testing for them!
Project and quality management

The arrangements for the management of the project must be agreed. Among these
would be frequency and nature of progress meetings and the progress information to be
supplied to the customer. The contract could require that appropriate ISO 9000-series
standards be followed. The ISO 12207 standard provides for the customer to have access to
quality documentation generated internally by the supplier, so that the customer can ensure

4 - 27 Software Project Management

 Project Management and Control
that there is adherence to standards.
Timetable

This provides a schedule of when the key parts of the project should be completed. This
timetable will commit both the supplier and the customer. For example, the supplier might be
able to install the software on the agreed date only if the customer makes the hardware
platform available at that point.
Price and payment method

Obviously the price is very important! What also needs to be agreed is when the
payments are to be made. The supplier's desire to be able to meet costs as they are incurred
needs to be balanced by the customer's requirement to ensure that goods and services are
satisfactory before parting with their money.
Miscellaneous legal requirements

This is the legal small print. Contracts often have clauses that deal with such matters the
legal jurisdiction that will apply to the contract, what conditions would apply to the sub-
contracting of the work, liability for damage to third parties, and liquidated damages.
Liquidated damages are estimates of the financial losses that the customer would suffer if the
supplier were to fall short of their obligations. It is worth noting that under English law, the
penalties laid down in penalty clauses must reflect the actual losses the customer would suffer
and cannot be unrealistic and merely punitive. Even this limitation will not be enough in some
cases as far as the supplier is concerned. As computer systems assume increasingly critical
roles in many organizations and in safety-critical systems can even be life-threatening in the
case of malfunction, the possible consequential damage could be very great. Suppliers will not
unnaturally try to limit this kind of liability. The courts (in England and Wales) have tended to
look critically at such attempts at limiting liability, so that suppliers will, in the case of major
contracts, take out insurance to cover such liabilities.
If there is a dispute, resorting to litigation, while being lucrative to the lawyers
involved, is both time-consuming and expensive. An alternative is to agree that disputes be
settled by arbitration. This requires that any dispute be referred to an expert third party whose
decision as to the facts of the case is binding. Even this procedure is seldom quick and
inexpensive and another option is alternative dispute resolution where a third party acts as a
mediator who has only an advisory capacity and attempts to broker an agreement between the
two sides.

4.7.5 Contract Management

 Contract management is a continuous process, starting with analysis and evaluation of

4 - 28 Software Project Management

 Project Management and Control
the customer’s inquiry, and carrying on until contract closure, upon fulfillment of all
contractual obligations.

Fig. 4.7.3

 It is the process of managing contract creation, execution and analysis to maximize

operational and financial performance at an organization, all while reducing financial
risk. Organizations encounter an ever-increasing amount of pressure to reduce costs and
improve company performance. Contract management proves to be a very time-
consuming element of business, which facilitates the need for effective and automated
contract management system.

4.7.5.1 The Fundamentals of Contract Management

When two companies wish to do business with each other, a contract specifies the
activities entered into by both organizations and the terms through which they will each fulfill
their parts of the agreement. Contracts affect business profitability in a very large way due to
the emphasis on revenue and expenses. When a contract is phrased poorly, one organization
might lose countless thousands of dollars over a simple technicality they lacked the resources
to identify. Effective contract management can ultimately create a powerful business
relationship and pave the road to greater profitability over the long-term, but only when
managed correctly.
4.7.5.2 Elements of Successful Contract Management

It isn’t enough that an organization has professionals in place to handle contract

management. Employees must be augmented with the presence of processes and software
companions to satisfy increasing compliance and analytical needs. When a contract
management strategy is successfully implemented, organizations can expect to see :
 The expected business benefits and financial returns are being realized.
 The supplier is cooperative and responsive to the organization’s needs.
 The organization encounters no contract disputes or surprises.
 The delivery of services is satisfactory to both parties.

4.7.5.3 Contract Management Process

4 - 29 Software Project Management

 Project Management and Control
Contracts play a significant role in the end-of-quarter crunch and are broken up into
stages to organize efforts and structure the typical contract process. When done manually,
creating a contract can prove quite time consuming. The process includes the following steps :
1. Initial requests : The contract management process begins by identifying contracts and
pertinent documents to support the contract’s purpose.
2. Authoring contracts : Writing a contract by hand is a time-consuming activity, but
through the use of automated contract management systems the process can become
quite streamlined.
3. Negotiating the contract : Upon completion of drafting the contract, employees should
be able to compare versions of the contract and note any discrepancies to reduce
negotiation time.
4. Approving the contract : The instance in which most bottlenecks occur is getting
management approval. Users can preemptively combat this by creating tailored
approval workflows, including parallel and serial approvals to keep decisions moving at
a rapid pace.
5. Execution of the contract : Executing the contract allows users to control and shorten
the signature process through the use of eSignature and fax support.
6. Obligation management : This requires a great deal of project management to ensure
deliverables are being met by key stakeholders and the value of the contract isn’t
deteriorating throughout its early phases of growth.
7. Revisions and amendments : Gathering all documents pertinent to the contract’s
initial drafting is a difficult task. When overlooked items are found, systems must be in
place to amend the original contract.
8. Auditing and reporting : Contract management does not simply entail drafting a
contract and then pushing it into the filing cabinet without another thought. Contract
audits are important in determining both organizations’ compliance to the terms of the
agreement and any possible problems that might arise.
9. Renewal : Using manual contract management methods can often result in missed
renewal opportunities and business revenue lost. Automating the process allows an
organization to identify renewal opportunities and create new contracts.

4.8 Project Monitoring and Controlling Process in Detail

 The Monitoring and Control Process Group consists of those processes performed to
observe project execution so that potential problems can be identified in a timely
manner and corrective action can be taken, when necessary, to control the execution of
the project.
4 - 30 Software Project Management
 Project Management and Control
 Project Monitoring and Control activities take place in parallel with Project Execution
Process Group activities so that, while the project work is being executed, the project is
being monitored and controlled by implementing the appropriate level of oversight and
corrective action.

 The project is observed and measured regularly against the project plan to ensure that
the project is within acceptable variances of cost, schedule and scope, and that risks and
issues are continually monitored and corrected as needed
 The executing, monitoring, and controlling phases of the project management lifecycle
consists of completing and managing the work required to meet the project objectives.
This phase also ensures that the project performance is monitored and adjustments to
the project schedule are made as needed.

Fig. 4.8.1

Need of project monitoring and controlling

 Simply because we know that things don’t always go according to plan (no matter how
much we prepare).
 To detect and react appropriately to deviations and changes to plans.
 To be proactive in finding issues ahead of time and taking corrective
action.
4.8.1 Techniques for Monitoring and Control

 Earned Value Analysis

o A way of measuring overall performance (not individual task) is using an aggregate
performance measure - Earned Value.

4 - 31 Software Project Management

 Project Management and Control
o Earned value of work performed (value completed) for those tasks in progress
found by multiplying the estimated percent physical completion of work for each
task by the planned cost for those tasks. The result is amount that should be spent
on the task so far. This can be compared with actual amount spent.
 Critical Ratio
o Sometimes, especially large projects, it may be worthwhile calculating a set of
critical ratios for all project activities.
o The critical ratio is
Actual process Budgeted cost
Scheduled progress Actual cost
o If ratio is 1 everything is probably on target
o The further away form 1 the ratio is, the more we may need to investigate
How these processes affect the project schedule

1. Updates to the schedule model data and baseline

2. Performance measurements
3. Requested changes
4. Recommended corrective actions
5. Updates to organizational process assets
6. Activity list and activity attribute updates
7. Updates to the Project Management Plan

4 - 32 Software Project Management