Upload
edwina-allison
View
213
Download
0
Embed Size (px)
Citation preview
1© 2005 KAZ Group Ltd. All rights reserved. Confidential.© 2005 KAZ Group Ltd. All rights reserved. Confidential.
QMS for …Project Managers
Presented by:Bram van OosterhoutQuality Manager
Friday 26 August 2005
The bitterness of low quality remains long
after the sweetness of low price is forgotten
2© 2005 KAZ Group Ltd. All rights reserved. Confidential.
Evolutionary delivery
Agenda
Setting the scene (Mil Std 498, Risk profiles) Approaches used in KAZ Results achieved at KAZ Your experience and views
3© 2005 KAZ Group Ltd. All rights reserved. Confidential.
Start with:HIC case study cost/FP for HICQIPS idemWhy?Risks (no mitigations)Risks + Hic ratingRisks + HIC rating + QIPS ratingSolution ED successfully deployed on QIPS, attempted on HIC.MIL-STD 498Etc…
4© 2005 KAZ Group Ltd. All rights reserved. Confidential.
Two case studies
PRISM project Start date Nov 2003End date June 2005 Duration 20 months Planned Builds: 6 Delivered releases 3 Release Planned Actual milestone effort Milestone effort 1 2 3
QIPS project Start date Jul 2004 End date June 2005 Duration 20 months Planned releases: 3 Delivered releases 3 Release Planned Actual milestone effort Milestone effort 6 Sep 04 3145 7 Nov 04 2082 9 Mar 05 4526
5© 2005 KAZ Group Ltd. All rights reserved. Confidential.
Major risks in the delivery of software
# There is a risk that …
1 … the compressed timeframe forces a partial delivery by a prescribed date,
2 … the requirements discovery phase exceeds the scheduled period.
3 … the scope of the deliverable is underestimated.
4 … constant change leads to rework and waste.
5 … the production environment does not meet specification.
6© 2005 KAZ Group Ltd. All rights reserved. Confidential.
… active risk at HIC
# There is a risk that … Active HIC
1 … the compressed timeframe forces a partial delivery by a prescribed date,
Yes
2 … the requirements discovery phase exceeds the scheduled period.
Very yes
3 … the scope of the deliverable is underestimated.
Maybe
4 … constant change leads to rework and waste.
Yes
5 … the production environment does not meet specification.
Very yes
7© 2005 KAZ Group Ltd. All rights reserved. Confidential.
… active risks at QIPS
# There is a risk that … Manifest HIC Manifest QIPS
1 … the compressed timeframe forces a partial delivery by a prescribed date,
Yes No
2 … the requirements discovery phase exceeds the scheduled period.
Very yes No
3 … the scope of the deliverable is underestimated.
Maybe No
4 … constant change leads to rework and waste.
Yes Somewhat
5 … the production environment does not meet specification.
Very yes No
8© 2005 KAZ Group Ltd. All rights reserved. Confidential.
Problem statements
How can we deliver projects like HIC (single contract, multiple releases) with the same predictability and productivity as we achieve in QIPS (one contract per release)?
Why are we unsuccessful in mitigating the major risks that threaten our delivery in single contract deliveries?
What do you see as the obstacles to success?
9© 2005 KAZ Group Ltd. All rights reserved. Confidential.
Mil Std 498 – Software development and documentation
Describes the systems development lifecycle Ref: http://www.abelia.com/498pdf/roadmap.pdf
Recognises that one size does NOT fit all Appendix G Guidance on program strategies, tailoring and build planning Distinguishes three major strategies
Program Strategy: Grand design
Incremental(Preplanned product improvement)
Evolutionary
Define all requirements first? Yes Yes No
Multiple development cycles?
No Yes Yes
Field interim software? No Maybe Yes
10© 2005 KAZ Group Ltd. All rights reserved. Confidential.
Major risks in the delivery of software
# There is a risk that … Successful mitigation strategies
1 … the compressed timeframe forces a partial delivery by a prescribed date,
Prioritise the functionality and deliver early
2 … the requirements discovery phase exceeds the scheduled period.
Prioritise the requirements and obtain agreement on a high priority, deliverable subset early.
3 … the scope of the deliverable is underestimated.
Perform a requirements verification early.
4 … constant change leads to rework and waste.
Do not accept change to units in construction.
5 … the production environment does not meet specification.
Deliver a minimal functionality release early..
11© 2005 KAZ Group Ltd. All rights reserved. Confidential.
Evolutionary delivery is preferred
# Risk Define all requirements first?
Multiple development cycles?
Field interim software?
1 Compressed timeframe No Yes Yes
2 Schedule blowoutNo Yes Maybe
3 Scope underestimated Yes
4 Constant changeNo Yes Yes
5 Environment configuration No Yes Yes
Considering:• the three defining characteristics for the selection of a delivery strategy and • the known, successful mitigation strategies employed to mitigate our major risks
an evolutionary delivery is our best response to the risks we are facing.
12© 2005 KAZ Group Ltd. All rights reserved. Confidential.
Task based contract – a clarification
When we tender for panels, we advocate a task based contract model
Work pattern
Task size
Assessment Detailed analysis Do work
Small X
Medium X X
Large X X X
The contract model is successful in classifying work and mitigating risk for a single delivery.
The contract model can be applied successfully to support an evolutionary delivery through repeated (assessment, do work) cycles
An evolutionary delivery will perform the assessment of the next cycle in parallel with the do work of the previous one.
13© 2005 KAZ Group Ltd. All rights reserved. Confidential.
14© 2005 KAZ Group Ltd. All rights reserved. Confidential.
15© 2005 KAZ Group Ltd. All rights reserved. Confidential.
16© 2005 KAZ Group Ltd. All rights reserved. Confidential.
17© 2005 KAZ Group Ltd. All rights reserved. Confidential.
18© 2005 KAZ Group Ltd. All rights reserved. Confidential.
19© 2005 KAZ Group Ltd. All rights reserved. Confidential.
20© 2005 KAZ Group Ltd. All rights reserved. Confidential.
Integrating UML into the KAZ methodology (2)
Inception Elaboration Construction Transition
preliminary iteration
Iter #t+1
Iter #2
Iter #1
Iter #t
Iter #c+1
Iter #c
Iter #c+2
Scope A Background, B Scope definition •
Environment
Phases
UI & Design F System design •
Requirements Analysis E Detailed requirements •
Configuration and Change management D Change request, K PromotionsProject management C Release schedule •, S Status reports
Build & Unit test Baselined Source code & executables
Deploy N Release notes, O Patch notes
Test H Test scripts •, J Test results
Workflow engineering products
Organisation in time
Workflow support products
• See ASP/R: [QMS]/Advisory/SmallProjectDevelopment/SmallProjectDevelopmentProcess.htm