Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
ICEBERG: a different look at 
Software Project Management 
Luigi Buglione 
SchlumbergerSema / UQÀM 
Rome, Italy 
Email: lb...
Agenda 
• Introduction 
• Evolution and contribution of Quality Approaches 
– Evolution of Quality Management frameworks 
...
Agenda 
• Introduction 
• Evolution and contribution of Quality Approaches 
– Evolution of Quality Management framework 
–...
Introduction 
Project Management has been defined in the PMBOK (1996 ed.) as 
“the application of knowledge, skills, tools...
Introduction 
• Starting point - every project should be properly managed taking 
into account 4 dimensions (Time, Cost, Q...
Agenda 
• Introduction 
• Evolution and contribution of Quality Approaches 
– Evolution of Quality Management framework 
–...
Agenda 
• Introduction 
• Evolution and contribution of Quality Approaches 
– Evolution of Quality Management framework 
–...
Evolution of Quality Management frameworks 
• Quality Management System (QMS) can be viewed as a risk 
mitigation strategy...
Evolution of Quality Management frameworks 
9 Luigi Buglione & Alain Abran © 2002
Agenda 
• Introduction 
• Evolution and contribution of Quality Approaches 
– Evolution of Quality Management framework 
–...
SPI models and QM models 
• To be competitive on the market, QA is not sufficient 
• First solution: to move towards SP(A)...
SPI models and QM models 
• Final solution: to merge the two families of methods into a single, 
stronger and reinforced a...
Agenda 
• Introduction 
• Evolution and contribution of Quality Approaches 
– Evolution of Quality Management framework 
–...
Software Project Measurement frameworks 
• Several Software Project Measurement (SPM) frameworks help in the 
measurement ...
Software Project Measurement frameworks 
FAMILY 
METHOD 
STRENGTHS WEAKNESSES 
SPAI • Path to organizational 
maturity 
15...
Agenda 
• Introduction 
• Evolution and contribution of Quality Approaches 
– Evolution of Quality Management framework 
–...
The ICEBERG approach 
• Objective: to leverage the ICE approach towards a better project risk 
management 
• How to do it?...
The ICEBERG approach 
18 Luigi Buglione  Alain Abran © 2002
The ICEBERG approach 
• What is required? 
• To figure out what is below the waterline level (more 
information on the pro...
The ICEBERG approach 
• Are the right entities captured? 
At least, two more entity types have to be taken into account: 
...
The ICEBERG approach 
• STAR (Software entities TAxonomy Revised) 
21 Luigi Buglione  Alain Abran © 2002
The ICEBERG approach 
• What is missing in ICE? The missing point is the “strategy” issue 
typical in Performance Manageme...
The ICEBERG approach 
A possible schema of models to apply in an ICEBERG context could be as 
follows: 
FAMILY 
METHOD 
FR...
The ICEBERG approach 
• But which measures can be used with STAR? 
Two points have to be stressed: 
1) matching software e...
The ICEBERG approach 
1) matching software entities with ICT BSC perspectives 
Software Entity 
1st layer 2nd layer 3rd la...
The ICEBERG approach 
2) search and list possible measures/indicators for each of the ICT BSC 
perspectives (1/3) 
Softwar...
The ICEBERG approach 
2) search and list possible measures/indicators for each of the ICT BSC 
perspectives (2/3) 
Softwar...
The ICEBERG approach 
2) search and list possible measures/indicators for each of the ICT BSC 
perspectives (3/3) 
Softwar...
Agenda 
• Introduction 
• Evolution and contribution of Quality Approaches 
– Evolution of Quality Management framework 
–...
Conclusions 
• Managing a project requires to take into account several 
organizational and project aspects, in addition t...
Conclusions 
• Some furtherissues: 
• the way an ICT BSC could be applied (traditional BSC way, multi-level 
BSC) 
• the w...
QA 
Thanks for your attention! 
32 Luigi Buglione  Alain Abran © 2002
ICEBERG: a different look at 
Software Project Management 
Luigi Buglione 
SchlumbergerSema / UQÀM 
Rome, Italy 
Email: lb...
Upcoming SlideShare
Loading in …5
×

ICEBERG: a different look at Software Project Management

1,401 views

Published on

Every project – whatever the application field – should be managed taking into account at least four dimensions: Time, Cost, Quality and Risk. To manage these dimensions, a key tool for a Project Manager is to increase project visibility, defined as the amount of information about the project associated with its probability of occurrence. This paper uses the “iceberg” metaphor to introduce the ICEBERG (Improvement after Control and Evaluation-BasEd Rules and Guidelines) approach that can help Project Managers through the use of standard (de jure and de facto) ICT methods and techniques. This approach focuses not only on the management, and measurement, of resources, process and product, but also of the project and the organization itself. A list of candidate measures related to these 5 entities is suggested for a comprehensive software measurement plan in order to reduce project risk.

Published in: Software
  • Be the first to comment

ICEBERG: a different look at Software Project Management

  1. 1. ICEBERG: a different look at Software Project Management Luigi Buglione SchlumbergerSema / UQÀM Rome, Italy Email: lbuglione@rome.sema.slb.com Alain Abran Ecole de Technologie Superieure Montréal, Québec, Canada Email: aabran@ele.etsmtl.ca IWSM2002 12th International Workshop on Software Measurement Magdeburg, October 7-9, 2002 Germany
  2. 2. Agenda • Introduction • Evolution and contribution of Quality Approaches – Evolution of Quality Management frameworks – Software Process Improvement models and Quality Models – Software Projects measurement frameworks • The ICEBERG approach • Conclusions 2 Luigi Buglione & Alain Abran © 2002
  3. 3. Agenda • Introduction • Evolution and contribution of Quality Approaches – Evolution of Quality Management framework – Software Process Improvement models and Quality Models – Software Projects measurement frameworks • The ICEBERG approach • Conclusions 3 Luigi Buglione & Alain Abran © 2002
  4. 4. Introduction Project Management has been defined in the PMBOK (1996 ed.) as “the application of knowledge, skills, tools, and techniques to project activities in order to meet or exceed stakeholder needs and expectations from a project. Meeting or exceeding stakeholders needs and expectations invariably involves balancing competing demands among: • Scope, time, cost and quality • Stakeholders with differing needs and expectations • Identified requirements (needs) and unified requirements (expectations) The term project management is sometimes used to describe an organizational approach to the management of ongoing operations” 4 Luigi Buglione & Alain Abran © 2002
  5. 5. Introduction • Starting point - every project should be properly managed taking into account 4 dimensions (Time, Cost, Quality and Risk) according to best practices in the Project Management domain • Arrival point – an approach to reduce the occurrence of risks in projects • Question: how to do it? 5 Luigi Buglione & Alain Abran © 2002
  6. 6. Agenda • Introduction • Evolution and contribution of Quality Approaches – Evolution of Quality Management framework – Software Process Improvement models and Quality Models – Software Projects measurement frameworks • The ICEBERG approach • Conclusions 6 Luigi Buglione & Alain Abran © 2002
  7. 7. Agenda • Introduction • Evolution and contribution of Quality Approaches – Evolution of Quality Management framework – Software Process Improvement models and Quality Models – Software Projects measurement frameworks • The ICEBERG approach • Conclusions 7 Luigi Buglione & Alain Abran © 2002
  8. 8. Evolution of Quality Management frameworks • Quality Management System (QMS) can be viewed as a risk mitigation strategy. • Three main stages in the evolution of QM frameworks: • QC - Quality Control • QA - Quality Assurance • TQM - Total Quality Management (QI - Quality Improvement) 8 Luigi Buglione & Alain Abran © 2002
  9. 9. Evolution of Quality Management frameworks 9 Luigi Buglione & Alain Abran © 2002
  10. 10. Agenda • Introduction • Evolution and contribution of Quality Approaches – Evolution of Quality Management framework – Software Process Improvement models and Quality Models – Software Projects measurement frameworks • The ICEBERG approach • Conclusions 10 Luigi Buglione & Alain Abran © 2002
  11. 11. SPI models and QM models • To be competitive on the market, QA is not sufficient • First solution: to move towards SP(A)I models and frameworks, such as CMMI, SPICE, Bootstrap… • But...: some areas are not covered (although complementary), such as documentation, customer complaints management, servicing….these issues are largely tackled by QMs such as ISO 9001 TOPIC SW-CMM V.1.1 ISO 9001:1994 ISO 9001:2000 Corrective actions L2 KPA SPTO, Goal 2 – Activity 6 4.14.2 8.5.2 Prevention of problems L5 KPA DP 4.14.3 8.5.3 Resources Abilities Common Feature in every KPA 4.1.2.2 6.1 + 6.2.1 Training Abilities Common Feature in every KPA 4.18 6.2.2 Audits L2 KPA SQA, Verification KP in all KPAs 4.17 8.2.2 + 8.2.3 Process and lifecycle L2 KPA SPP, L3 KPA OPD 4.4 7.2 + 7.3.x definition 11 Luigi Buglione & Alain Abran © 2002 4.9 6.3 + 6.4 + 7.5.1 + 7.5.2 Continuous Improvement L5 4.14 8.5.2 + 8.5.3 4.17 8.2.2 + 8.2.3
  12. 12. SPI models and QM models • Final solution: to merge the two families of methods into a single, stronger and reinforced approach • This path to quality excellence is called ICE (Improvement after Control & Evaluation) • A path to excellence: through a gradual and constant increase of the maturity and capability level of an organization 12 Luigi Buglione & Alain Abran © 2002
  13. 13. Agenda • Introduction • Evolution and contribution of Quality Approaches – Evolution of Quality Management framework – Software Process Improvement models and Quality Models – Software Projects measurement frameworks • The ICEBERG approach • Conclusions 13 Luigi Buglione & Alain Abran © 2002
  14. 14. Software Project Measurement frameworks • Several Software Project Measurement (SPM) frameworks help in the measurement activity, but not for the identification and selection of the right entities to measure • The usual triad of measurable entities is: resources, process, product • Strengths: general • Weaknesses: it misses the broader project context • Solution: to move up to the “ICE” approach, taking into account also the project risks and the causal chains generated by the linkage among the processes and goals of an organization (i.e. as in the Balanced Scorecard approach) • But…: a BSC also misses something... 14 Luigi Buglione & Alain Abran © 2002
  15. 15. Software Project Measurement frameworks FAMILY METHOD STRENGTHS WEAKNESSES SPAI • Path to organizational maturity 15 Luigi Buglione & Alain Abran © 2002 • No focus on the business organisational strategy. Pre-defined path from L1 to L5 (staged Model) QM • Strong focus on Controls and Assurance • Little attention to improvements (even with the ISO Vision 2000 series) PM (BSC) • Causal Chain among perspectives • No clear nor defined action plan after measurement and the strategy map
  16. 16. Agenda • Introduction • Evolution and contribution of Quality Approaches – Evolution of Quality Management framework – Software Process Improvement models and Quality Models – Software Projects measurement frameworks • The ICEBERG approach • Conclusions 16 Luigi Buglione & Alain Abran © 2002
  17. 17. The ICEBERG approach • Objective: to leverage the ICE approach towards a better project risk management • How to do it? Through the achievement of a better project visibility, defined as: i available _ inf oi *%probability _ occurrence • How to represent it? Through the iceberg metaphor 17 Luigi Buglione Alain Abran © 2002
  18. 18. The ICEBERG approach 18 Luigi Buglione Alain Abran © 2002
  19. 19. The ICEBERG approach • What is required? • To figure out what is below the waterline level (more information on the project: through an in depth measurement activity) • To implement mitigation strategies to maintain a sufficient distance between the ship and the iceberg to avoid crashes (problems solved on time) 19 Luigi Buglione Alain Abran © 2002
  20. 20. The ICEBERG approach • Are the right entities captured? At least, two more entity types have to be taken into account: • the Organization itself • the Projects the Organization is running and managing 20 Luigi Buglione Alain Abran © 2002
  21. 21. The ICEBERG approach • STAR (Software entities TAxonomy Revised) 21 Luigi Buglione Alain Abran © 2002
  22. 22. The ICEBERG approach • What is missing in ICE? The missing point is the “strategy” issue typical in Performance Management techniques such as the BSC • Solution: Expand the ICE view to ICEBERG (Improvement after Control Evaluation-BasEd Rules and Guidelines) 22 Luigi Buglione Alain Abran © 2002
  23. 23. The ICEBERG approach A possible schema of models to apply in an ICEBERG context could be as follows: FAMILY METHOD FRAMEWORK CHOSEN WHICH USAGE… SPAI • CMMI v.1.1 Continuous Model 23 Luigi Buglione Alain Abran © 2002 • For the maturity path and the improvement actions (according to BITS) QM • ISO 9001:2000 • For the Quality Assurance topics PM (BSC) • ESI’s BITS (5 perspectives) • QEST/LIME [BUGL01] [ABRA02] • For the Performance Management issues (general framework) • For the measurement of the performances obtained applying BITS
  24. 24. The ICEBERG approach • But which measures can be used with STAR? Two points have to be stressed: 1) matching software entities with ICT BSC perspectives 2) search and list possible measures/indicators for each of the ICT BSC perspectives 24 Luigi Buglione Alain Abran © 2002
  25. 25. The ICEBERG approach 1) matching software entities with ICT BSC perspectives Software Entity 1st layer 2nd layer 3rd layer 25 Luigi Buglione Alain Abran © 2002 Main ICT BSC perspective(s) involved Organization Financial Project Infrastructure Innovation Resources People, Customer (requirements), Infrastructure Innovation Process Process Product Process, Customer (feedback)
  26. 26. The ICEBERG approach 2) search and list possible measures/indicators for each of the ICT BSC perspectives (1/3) Software Measures /Indicator Notes Entity Organisation - ROI (Return On Investment) - ROS (Return On Sales) - ROCE (Return On Capital Employed) - EVA (Economic Value Added) - Breakeven time - Percent of revenue from products developed in last 4 years - Proposal win % - Cost performance - Net present value of cash outflows for development and commercialization and the inflows from sales - … 26 Luigi Buglione Alain Abran © 2002 Measures linked to financial issues, as in the Financial perspective in the ICT BSC Project - Development cycle time trend (normalized to program complexity) - Earned Value (EV) - Schedule performance - Program/project cost performance - Actual staffing (hours or headcount) vs. plan - Personnel turnover rate % of milestone dates met - Schedule performance - Milestone or task completion vs. plan - On-schedule task start rate - Phase cycle time vs. plan - Time-to-market or time-to-volume - … Measures typical for a Project Manager in deploying his activity, looking at both Technical and Economical viewpoints
  27. 27. The ICEBERG approach 2) search and list possible measures/indicators for each of the ICT BSC perspectives (2/3) Software Measures /Indicator Notes Entity Resources - Percent project personnel receiving team building/team launch training/facilitation - Average training hours per person per year or % of payroll cost for training annually - IPT/PDT turnover rate or average IPT/PDT turnover rate - Percent core team members physically collocated - Staffing ratios (ratio of each discipline's headcount on project to number of design engineers) Personnel ratios - Staffing (hours) vs. plan - Requirements Coverage - Technology Impact - … 27 Luigi Buglione Alain Abran © 2002 Measures intended to focus on the management of people, infrastructure and materials, searching for information about the degree of efficiency they are managed Process - Product ship date vs. announced ship date or planned ship date - Mean time between failure (MTBF) - Labor hours or labor hours / target labor hours - Mean time to repair (MTTR) - Productivity - Cycle Time - Defect Containment - Process Audit Findings - Reference Model Ratings - … Measures intended to focus on the way a certain process (typical to a certain industry) is deployed, in direct or indirect way
  28. 28. The ICEBERG approach 2) search and list possible measures/indicators for each of the ICT BSC perspectives (3/3) Software Measures /Indicator Notes Entity Product - Product performance or product performance / target product performance or technical performance measures (e.g., power output, mileage, weight, power consumption, mileage, range, payload, sensitivity, noise, CPU frequency, etc.) - Number of parts or number of parts / number of parts for last generation product - Defects per million opportunities or per unit - Field failure rates or failure rates per unit of time or hours of operation - Engineering changes after release by time period - Design/build/test iterations - % of requirements analyzed/simulated - … 28 Luigi Buglione Alain Abran © 2002 Measures to focus on the final product
  29. 29. Agenda • Introduction • Evolution and contribution of Quality Approaches – Evolution of Quality Management framework – Software Process Improvement models and Quality Models – Software Projects measurement frameworks • The ICEBERG approach • Conclusions 29 Luigi Buglione Alain Abran © 2002
  30. 30. Conclusions • Managing a project requires to take into account several organizational and project aspects, in addition to the traditional IPO view • Again, it is not possible to consider only the QA view, but in a competitive market an Organization absolutely needs to be proactive and move towards a Quality Improvement views on Quality issues • ICE represents a first step towards this new vision of Quality; but it misses the strategical part of the “journey” • ICEBERG represents the step beyond, merging SPAI+QM+PM models and frameworks in a unique, integrated view, increasing the project visibility for Project Managers • The way to manage an ICEBERG passes always through measurement: the STAR taxonomy is the answer 30 Luigi Buglione Alain Abran © 2002
  31. 31. Conclusions • Some furtherissues: • the way an ICT BSC could be applied (traditional BSC way, multi-level BSC) • the way to move from a traditional approach to manage software project towards the STAR logic • the way risk can be tackled and minimised using an ICT BSC (in each perspective or in an overall way) 31 Luigi Buglione Alain Abran © 2002
  32. 32. QA Thanks for your attention! 32 Luigi Buglione Alain Abran © 2002
  33. 33. ICEBERG: a different look at Software Project Management Luigi Buglione SchlumbergerSema / UQÀM Rome, Italy Email: lbuglione@rome.sema.slb.com Alain Abran Ecole de Technologie Superieure Montréal, Québec, Canada Email: aabran@ele.etsmtl.ca IWSM2002 12th International Workshop on Software Measurement Magdeburg, October 7-9, 2002 Germany

×