UNIT 4

MONITORING AND CONTROL

Syllabus• Creating framework• Collecting the data• Visualizing progress• Cost monitoring• Earned value• Prioritizing monitoring• Getting project back to target• Change control• Managing contracts• Introduction• Types of contracts• Stages in contract of placement• Typical terms of a contract• Contract management• Acceptance

CREATING FRAMEWORK

• Project Framework consists of – Understanding Project Control Cycle and – Establishing Project structure

Make a project plan

Start

Publish the plan to all stake holders

Kick of the project

Collect data from reliable sources

Update project plan based on collected data (also called project tracking)

Revise the plan

Take corrective actions

Analyse root causesProgress satisfying?

Is project plan requires revision?

No

No

Yes

B

Project completed

Review project

Formally inform all stakeholders

Document the lessons learnt

End

Yes

No B

Project steering committee

Comprises of top level executives from customer and contractor

Project coordination committee (customer)

Project coordination committee (contractor)

Project manager (customer) Project manager (contractor)

Dept Managers

Team

(IT Infrastructure)

(System Analysis)

(Testing) (user Groups)

Team Leaders

(Domain consultant)

(Analysis/design)

(Coding/testing)

Documentation/Sys Admin)

Project Tracking

• Collect Data• Cross Check its validity

– Some sources to collect / Cross check data ( next slide)

• Update project plan– If it involves time and cost ( slipping out of

control)

( PROGRESS REPORTS)

Collecting the Data

Project progress report Example Remarks

Verbal

Formal

Regular

Periodic (weekly/ fortnightly/

monthly) meetings

Whatever is verbally told in the

meeting must be recorded in the

minutes of the meetings

Verbal

Formal

Adhoc

Milestone achievements/ any

completion of stage etc.

Must be followed up with written

report

Written

Formal

Regular

Weekly/fortnightly/monthly

project progress reports

Job sheets etc

Generally, these reports are sent in a

predefined format

Written

Formal

Adhoc

Flash reports (triggered by an

event)

Change report

Exception report

Project manager reviews the impact

on the project due to the event.

Verbal

Informal

Adhoc

Corridor talk

Social interaction

Coffee break discussion

Only gives advance information to

be alert and take any preventive

action.

Not official without written report.

Job card

Employee Name: __________ Project Name: __________

Report for the period from _______ to _______

Chargeable hours

Project Acti

vity

Description Hours worked % completed Plan

ned

com

pleti

on

Expected

completion

P201 A 23 Testing integration

between module A

and module B

15 25% 25/7/

11

20/8/11

- - - - - - -

Total -

Comments by team leaders/Project manager:

- - - -

Non Chargeable hours

Project Description Hours Remarks

P201

-

-

Network failure in our center

-

-

2

-

-

-

-

-

Total -

Risk Reports• “Traffic light technique’ for risk reporting followed by IBM

• Step 1: Identify the first level (higher level) key elements to assess the work

• Step 2: Break down the first level key elements to second level elements • Step 3: Judge each of the second level element’s progress in 3 scales as

below.

Green(G) – As per targetAmber (A) – Not as per target but can be brought back to controlRed (R) – Not as per target and cannot be brought back to control without involving additional cost/resource/time

• Step 4: Based on the second level assessment, judge the first level on the same 3 point scale (Green/Amber/Red)

• Step 5: Review all the first level assessments to decide on the overall assessment of the project.

Risk Assessment ReportName: ________________ Dated: __________

Project Name: __________ Ref: ____________Project Risk Level : _____R_____

First Level Activity-Risk LevelWeek No.

First level activity risk assessment

10

G

11

G

12

A

13

A

14

R

15 16

Second level activity-Risk level

a)Screen handling

b)DB update

c)Feedback message

d)Compilation

e)Test Run

f)Documentation

G

G

G

G

G

G

G

G

A

G

G

A

G

A

G

G

A

A

A

G

G

A

A

A

A

A

G

R

R

R

VISUALIZING PROGRESS

• Gantt Chart• Slip chart• Ball chart• Timeline graph

Gantt Chart - example

I.1.1 Identify need and benefits Meet with customers Identify needs and project constraints Establish product statement Milestone: product statement definedI.1.2 Define desired output/control/input (OCI) Scope keyboard functions Scope voice input functions Scope modes of interaction Scope document diagnostics Scope other WP functions Document OCI FTR: Review OCI with customer Revise OCI as required; Milestone; OCI definedI.1.3 Define the functionality/behavior Define keyboard functions Define voice input functions Decribe modes of interaction Decribe spell/grammar check Decribe other WP functions FTR: Review OCI definition with customer Revise as required Milestone: OCI defintition completeI.1.4 Isolate software elements Milestone: Software elements definedI.1.5 Research availability of existing software Reseach text editiong components Research voice input components Research file management components Research Spell/Grammar check components Milestone: Reusable components identifiedI.1.6 Define technical feasibility Evaluate voice input Evaluate grammar checking Milestone: Technical feasibility assessedI.1.7 Make quick estimate of sizeI.1.8 Create a Scope Definition Review scope document with customer Revise document as required Milestone: Scope document complete

week 1 week 2 week 3 week 4Work tasks week 5

The Slip chart - example

The Ball chart

01/1/11

01/1/11

Planning

Contract finalise

15/1/11

15/1/11

01/1/11

01/1/11

31/1/11

05/2/11

01/2/11

04/2/11

02/3/11

02/3/11

The Timeline graph

W 1 2 3 4 5 6

1

2

3

4

5

6

Planned time (weeks)

Actual

time (weeks)

Study Disc

uss

Document

COST MONITORING

• No indication about revised cost / completion time

Planned cost

Actual cost

Cumulative cost

Time

M1 M2 M3 M4 M5 M6

(months)

Cost graph with cost /time extension

Original cost Cumulative cost

Time

Today

Revised cost

Original comp date

Revised comp date

EARNED VALUE ANALYSIS

• Industry standard method of measuring a project's progress at any given point in time

• Forecasting its completion date and final cost• Analyzing variances in the schedule and

budget as the project proceeds • As work is completed, it is considered

"earned".

EVA Purpose

• EVA answers two key questions:– At the end of the project, is it likely that the cost

will be less than, equal to or greater than the original estimate?

– Will the project likely to be completed on time?

Calculating Earned Value

• Three key values for each activity in the WBS– The Planned Value (PV),

• Budgeted cost of work

– The Actual Cost (AC), • Cost of work performed

– The Earned Value (EV), • Value of work actually completed

– Cost Variance (CV) = EV – AC– Schedule Variance (SV) = EV – PV

– Cost Performance Index (CPI) = EV / AC– Schedule Performance Index (SPI) = EV / PV

– Negative SV means Behind Schedule (Time over Run)

– Negative CV means over budget ( Cost Over Run)

PRIORITIZING MONITORING

• Some key aspects to monitor– Critical path activities– Activities with no free float– Activities with less than a specified float– High risk activities– Activities using critical resources

GETTING PROJECT BACK TO TARGET

• Shorten the critical path– Increase the required resources – Make available resources, work overtime to

meet the deadline.– Ensure more efficient resources (specialist

outsourcing)

• Reconsider precedence requirements – Consider possibility of parallel activities.– Consider training ‘outside business hours’

Change Control

• Scientific techniques to control software changes is called Software Configuration Management - SCM.

Need for SW changes

• Changes in business strategy• New customer needs due to market driving forces • Reorganization of the business • Budgeting or Scheduling Constraints • New regulations imposed by Government • Changes in technology• Porting the application to a new operating system

Need for SCM

• Generally, most changes are justified • Changes could affect

– User Interface– Architecture– Database Structure – Coding

SCM Activities

• Identifying work products which could change • Establishing relationship amongst them• Defining mechanism to manage various

versions • Controlling the changes • Auditing and reporting changes made.

Some SCM terms • Baseline:

– IEEE Std. No. 610.12.1990 defines the baseline as “A specification or product or document which is formally reviewed and agreed upon, there after serves as the basis - This is called baseline”.

• Software Configuration Items (SCI)– A software configuration item is information created as part of

software engineering process.• Examples

– Approved Specifications– Approved Design – Approved Program Component (C, C++, VB, etc.,)– Version of compiler, Browser, or any automated tool (to produce

document or source code)

SCM Process

Version control

Change request/ control

SCI’s version m.n

Report layer (Engineering change order)

Audit layers

Identification

Change Control Diagram

Start

One or more users perceives the need for change

UMT considers the changes and takes a decision

Request For Change (RFC)

Send to ‘Development Team’‘Development Team’ reviews and prepares an impact report consisting of•Process change•Practicality•Cost•Easiness to users•SCI’s affected•Cost involved

Impact Report send to UMT

x

Deny Request

Accept request

Send to ‘User Management Team’ (UMT)

x

UMT considers the report and takes a decision

Impact report sent to ‘Change Control Board’, (CCB) (consisting of top executives

of both customer and contractor

Deny Request

CCB takes decision

Major change & out of CCB’s

financial powersDeny or

Hold

Accept

Deny

Send to project coordination/steering

committee for approval

Many small changes and within the CCB’s

financial powers

Deny or Holds

changes

Accepts

Informs project manager to go

ahead

Approves

PM informs development team to proceed

Development team raises request for all SCI’s with software configuration / version

control manager (called ‘check out’ request.)

All SCI’s sent to development team – software gets modified – recompiled –

tested - documented

Modified files send to version control with the ‘check in’ request

SCM checks in modified version of software and System Admin informed about patches

System admin sends patches to customer site with modified software + installation

and operation procedures

y

Works satisfactorily?

No Report to Development team for debugging

Update files in live space

Inform all users

Yes

End

MANAGING CONTRACTS

• Ways to acquire a software product – Bespoke development

• Inhouse• Contracted

– Off the shelf product deployment • Implemented by inhouse team• Implemented by contracted team

– Off the shelf product with customization by the product developers

Acquitition process

• ISO 12207 explains the procedure (acquitition process) when contracting a job outside.

• ‘Acquitition process’ is a set of procedures that a customer for software (also called ‘acquirer’) should follow in order to obtain the software from an external source

The acquisition and supply process

Initiation

Prepare RFP

Contract preparation Response to RFP

Initiation

CONTRACT SIGNING

Supplier monitoring

Acceptance & completion Delivery & completion

Execution

Planning

ACQUIRER SUPPLIER

RFP Contents

• System requirements• Scope of the project• Instruction to bidders• Proposed solution• List of software products• List of other requirements• Control of subcontracts• Technical constraints• Draft project plan

TYPES OF CONTRACTS

• Fixed Price• Time and Material• Fixed Price per delivered unit

Fixed Price Contract

• Supplier must execute all the commitments as described in the contract for a specific sum of money.

• The price is fixed and cannot be altered unless the contract is renegotiated.

Fixed Price Contract…

• Advantages– Known Expenditure/Income– Supplier Motivation– Client Control

• Disadvantages– Risk absorption– Difficulties in changes to requirement – Threat to quality– Supplier demand for more money

Time and Material Contract

• SW supplier will charge at a fixed rate per unit of effort.– (E.g.) different rates for a man programmer hour,

man-analyst hour, man-designer hour, man-manager hour –All already fixed

• Supplier and the acquirer will guestimate the efforts and time required at various levels to complete the project. This is only a ball park figure for both parties to plan their resources & activities and not the basis for final payment

Time and Material Contract…

• Advantages– Lack of price pressure( quality of software is likely to

be better since the pressure of price is not there )– Ease of requirement Changes

• Disadvantages– No Supplier role for cost effectiveness– Customer liability (absorbs all the risks associated

with poorly defined requirement, not well controlled change )

Fixed price per unit delivered contracts

• Prices are fixed for design, coding, implementation and support based on function points.

• Example– Our initial estimate of FP’s be 3800, in each

category – Design, Coding, Implementation and Support

– Our preferred supplier has quoted the following prices.

FP count Design cost/F

P(Rs)

Coding cost/FP(Rs)

Implementation cost/FP

(Rs)

Support cost/FP/y

ear(Rs)

Up to 1500

10,000 7000 18,000 5000

1500 – 2000

12,000 8,000 20,000 7,000

2000 – 3000

15,000 10,000 22,000 10,000

3000 – 4000

18,000 12,000 25,000 13,000

4000 – 5000

20,000 15,000 30,000 15,000

Budgeting

• Cost of design = Rs.5,04,00,000• Cost of coding = Rs.3,41,00,000• Cost of implementation = Rs.7,90,00,000• Cost of support = Rs.3,14,00,000

• Total budgeted cost = Rs.19.49 crores

Fixed price per unit delivered contracts …

• Advantages– Customer clarity– Competitive nature– Changing requirements – Supplier efficiency– Flexibility

• Disadvantages – Difficulty in measurements– Changing requirements

How an acquirer selects a supplier?

• Open tender process• Restricted tender process• Negotiated procedure

STAGES IN CONTRACT PLACEMENT

• Feasibility study• Requirement analysis• Evaluation plan• Invitation to tender• Evaluation of proposals• Decision on a supplier• Contract signing

STAGES IN CONTRACT PLACEMENT…

• Feasibility study ( Self convincing)– Cursory Requirements – Benefits to organisation– Technical / Financial Viability

• Requirement analysis ( Clarity on what is needed)– Functional requirements Mandatory– Non functional requirements Desirable– Domain requirement Wish List– Operational requirements– Performance requirements– Standards requirements and– Quality requirements

STAGES IN CONTRACT PLACEMENT…

• Evaluation plan– Meeting all mandatory requirements– Cost of the software– Experience in executing such projects– Reference from customers– Supplier’s financial strength– CV of their key employees– Site visit plan

TYPICAL TYPES OF THE CONTRACT

• Product contract from supplier (for use with license) – e.g MS Office from MS

• Product supply contract from reseller (for use with license) - e.g MS Office from INDISS

• Supply of various services• One-time Deployment services ( eg SAP, Tally)• One-time Training services ( eg NIIT)• Managed services ( eg Infosys manages NYSE)• Outsourced services ( Sutherland HP,MS call centers)• Maintenance services ( eg WIPRO with GM)

• Custom development services

Terms of a custom contract

• Price ( Payment schedule + Retention money)• Statement of work• Deliverables• Assumptions• Responsibilities• Estimated schedule • Service Level Agreements ( SLA)• Escrow clause

Other Clauses• Liquidated Damages

– claim damages to a specified limit • Exclusion or Limitation of Liability

– not liable for consequential damages • Whole agreement clause

– Other than what is mentioned in contract is not included ( like mail/ oral commitments)

• Arbitration • Jurisdiction ( Country / state laws)• Force majure • Warranty

CONTRACT MANAGEMENT • Responsibility

– Supplier• Work execution

– Acquirer• Managing and ensuring that the project is on right track

• Approvals– @every milestone

• Change Control– Use of SCM

• Sync of both parties– Periodic meetings and signed minutes– Periodic reports and acknowledgements

Acceptance / Project closing

• Acceptance testing• Use of Warranty period for fixing bugs• Invoking retention clause

Project Success Factors

• Considerable amount of management time• Effective negotiating skills (before contract is signed)• A software life time plan involving acquiring, using,

updating till the retirement of the software.• Commitment from all the parties (especially their top

management)• And above all, a very good friendly working

relationships at all levels between the supplier and the acquirer.

End of unit 4