UNIT 4 MONITORING AND CONTROL. Syllabus Creating framework Collecting the data Visualizing progress...
-
Upload
kory-potter -
Category
Documents
-
view
235 -
download
2
Transcript of UNIT 4 MONITORING AND CONTROL. Syllabus Creating framework Collecting the data Visualizing progress...
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