Some thoughts on Productivity in ICT Projects: measurable entities, requirements, possible impacts

WSPM/SGPS 2008
I° Workshop on Software Projects
Management
Madrid, 25 de Septiembre 2008

Some thoughts on Productivity in ICT projects:
measurable entities, requirements, possible impacts

Luigi Buglione

www.eng.it WSPM/SGPS 2008 – Luigi Buglione © 2008

Goals of the Presentation:
Presentation
 G1. To look at the entities to be measured and to be related
against stated information goals (project vs product)
 G2. to enlarge the possible project’s requirement taxonomy
from ISO/IEC 14143-1
 G3. From requirements to WBS: a process-oriented view
G4. Some thoughts on the Productivity definition

Source:
• L.Buglione, Some thoughts on Productivity in ICT projects, White Paper, version 1.2, March 2008, URL:
www.geocities.com/lbu_measure/fpa/fsm-prod-120e.pdf

www.eng.it WSPM/SGPS 2008 – Luigi Buglione © 2008 2

Introduction
A picture of your project

» Q: which level of control (granularity) has your project?

(a) (b)

or


G1. Entities to be measured
G1
IPO taxonomy

Resources Process Product

Measurement


G1
STAR taxonomy

Organization/ SBU

Project

Resources Process Product

FSU

Measurement


G1
Project & Product: another possible view

Container
(Project)

Content
(Product)


G1
Project “entity”: possible dimensions of analysis
entity

Functional
Functional

Technical
Technical Project
Quality
Quality

Other
Other


G1
Proposal & Side-Effects

• Proposal
 Clearly state the entity to which a FSM unit refers (product) and to which
dimension pertains (functional)
 Insert in the ISBSG Glossary of Terms (v. 5.9.1) a definition for “Project Size”
as a sub-item under the “Project” series of definition (currently there is only
the “Software Size” definition)
 Possible inputs: PMBOK 2004

• Side-Effects
 Relate the “product (functional) size” to the project (functional effort) when
determining the productivity rates
 Currently there is no indication in the ISBSG data about the % of non-
functional effort expressed by a project; it can be indirectly derived from
a certain PDR value by filtering the database according to technology,
programming language, etc…


G2. Enlarging the ISO/IEC 14143-1 req. taxonomy
G2
ISO/IEC 14143-1:2007
“Functionality” char in ISO 9126-1

• Functional User Requirements (FUR): “a sub-set of
the user requirements. The Functional User Requirements
represent the user practices and procedures that the
software must perform to fulfil the users’ needs. They
exclude Quality Requirements and any Technical
Requirements”
• Quality Requirements: “any requirements relating to
software quality as defined in ISO 9126:1991”
• Technical Requirements: “requirements relating to
the technology and environment, for the development,
maintenance, support and execution of the software”

Source:
» ISO/IEC14143-1:2007, Information Technology-Software Measurement-Functional Size Measurement-Part 1: Definitions of Concepts:
International Organization for Standardization, 2007
» IFPUG, Framework for Functional Sizing, Version 1.0, September 2003), International Function Point User Group, Westerville, Ohio, January
2004, URL: http://www.ifpug.org


G2
Implicit & Explicit Requirements

CMMI, PP: SP1.1

• Quality (ISO 9000:2005, §3.1.1): Degree to which a set of inherent characteristics
fulfils requirements.
 Note 2: “inherent”, as opposed to “assigned”, means existing in something, especially a
permanent characteristic

• Project (ISO 9000:2005, §3.4.3): unique process, consisting of a set of coordinated
and controlled activities with start and finish dates, undertaken to achieve an objective
conforming to specific requirements, including the constraints of time, cost and resources.

G2
ISO/IEC 14143-1:2007: a possible fourth type

O

• O (Other req): implicit requirements often refers to other natures than F/Q/T.
Typical processes to be considered could be the Organizational & Support
processes, in the SPI process models view (i.e. CMMI/ISO 15504)


G2

• Proposal
 Consider an enlarged view on ISO/IEC 14143-1 requirements taxonomy,
because the whole project scope should be taken into account.
 Analyzing a project classifying requirements by type would help to determine
which processes and related tasks should be included or not into a functional
count for determining (functional) productivity rates.
 Simplifying, the Q/T/O parts can be referred as “NF” (non-functional)
 Include these concepts and related definitions in the ISBSG Glossary of
Terms (v.5.9.1)
 Possible inputs: ISO 9000:2005, CMMI (PP, SP1.1), ISO/IEC
14143-1:2007

• Side-Effects
 The effort from the “O” part is a non-functional one. It could be initially
difficult to isolate such tasks and effort
 One misleading concept in some ICT professionals is that a FSM unit
measures the whole project


G3. From requirements to WBS
G3
Requirements, Processes, Tasks

• Project Management view on a project
 From high-level req (HLR) to tasks into a WBS, through a series of
refinements (RHRL). The “chain” would be:
HRL  RHLR  (process)  task

• Process grouping and effort classification
 CMMI has four groups of processes: Project, Process, Support, Engineering)
 ISO 15504 has five groups: Customer, Engineering, Management,
Organizational, Support)

 Rule of thumb: functional effort is mainly derived from Engineering processes,
thumb
excluding tasks related to Quality & Technical Requirements, as in ISO 14143-1,
and also from the “Other” requirements.


G3. From requirements to WBS
G3

• Proposal
 Consider in the analysis the nature of the processes from which a task in the
WBS is derived: it will help in determining the nature of the task itself and,
consequently, the nature of the effort (functional vs non-functional effort).
 Possible inputs: SPI process models (CMMI, ISO 12207/15504, …)

• Side-Effects
 Possible discussions about the level of granularity for a task, when not too
basic. In such case, a solution is to split a bigger task into two or more
refined ones, clarifying the nature of each activity. Otherwise, from a PM-
viewpoint, such tasks will be less checkable.
 The reference point should be always the process classification applied in an
organization, determining what does it mean “functional” and what not.
 A generic “Testing” activity could include both functional testing and non-functional
testing (i.e. performance tests), but the second one would not be in the scope of a
functional counting and relating usages.
 I.e., User Manuals refer to the SPICE’s SUP.1 process (Documentation) and the
effort to produce it cannot be the expression of a FUR, as meant in ISO/IEC
14143-1 (when misleading the ‘product’ with the ‘project’ entities.

G4. Some thoughts on the Productivity Definition
G4
Current view & issues

• Common definition of “Productivity”
 The amount of output created per unit input used
 Labour productivity is typically measured as output per labour-hour
• “Productivity” and FSMM
 In ICT project, a productivity figure is FSM unit / (project) work effort
 An example:
 Project type: SAP R/3 enhancement project
 Application size: 980 FP
 (project) effort: 1200 man-days (F:850m/d; Q:100; T:150; O:100)
 Productivity = (FP / Effort) = (980 FP / 1200 m-d) = 0.82 FP/m-d

• Some first-level observations
 The upper part of the formula refers to a product size unit, valid for the
functional viewpoint, while the lower part of the formula to the whole project.
 What about the functional productivity?
 If the effort distribution by type (F/Q/T/O or – at least – F vs NF) is not
known, it could be difficult for a project manager to compare projects with
potential different effort profiles, therefore not comparable for benchmarks 
lower R2 in next estimations

G4

• Q1: is the ratio (as currently applied) meaningful or not?
 Overall productivity is underestimated (no “Quality | Technical points”) on the upper
part of the formula to counterbalance the overall project effort on the lower part


G4

• Q2: what about technical impacts for a project manager?
 The current productivity value should be usable also for benchmarking
projects with different distributions of the overall effort (among the F/Q/T/O
parts)
 If the effort referred to Q/T/O tasks will increase:
 Planning issue: the number of FSM units will not increase, with a formal lower
productivity value
 Staffing issue:
 other roles could be requested (i.e. SOA architects, usability expert, …) and
with different costs on the project than traditional functional roles involved into
the deployment of FURs.
 A generic number of FTE (Full Time Equivalent) to be scheduled in terms of
time and costs is only a first-level information to consider in a bid/RFP.


G4

• Q3: what about the business impacts for a project manager?
 (project) Cost / FP (product) is a economical figure used in many ICT
contracts, heritage of the ’90s (yet included also in the first edition of IFPUG
“Guidelines to Software Measurement” – 1992)
Measurement
 Two not homogeneous portions in the formula
 The application of such derived measure for economic purposes could lead:
 to do not recognized any economic value for non-functional (NF) tasks in a project
or
 to overestimate the economic value of a FSM unit in order to comprehend also the
NF part of the software application under evaluation, but with a lower price (part
of the Functional side)
while they (F/NF) are simply two separated but integrated parts of a project
 An indirect evidence from the Albrecht’s 1979-84 versions:
 VAF’s GSCs reflect non-functional issues and…
 …the number of GSCs grew up from 10 up to 14, increasing the VAF incidence
from a ±25% to ±35% of UFP…
 …but ISO yet excluded from 1998 unadjusted versions from current FSM methods


G4

• Proposal
 Three possible applications of the productivity formula:
 FSM (product) unit /(project effort), but gathering at least the split of
project effort data into F vs NF effort
 F/Q/T/O (product) unit /(F/Q/T/O effort): more productivity figures per
effort type
 (project) unit /(project effort): one overall productivity figures for the
whole project, using a unique project size unit
 Project Delivery Rate (PDR) is the inverse of productivity (Effort/FP); modify
accordingly the ISBSG Glossary of Terms (v.5.9.1)
 Insert the “median” definition into the ISBSG Glossary of Terms, stressing its
relevance when dealing with size, effort and productivity values in the
estimation process, whatever the technique adopted

• Side-Effects
 More projects with the same productivity level (even if from the same cluster
of projects) could not necessarily represent homogeneous units to be
considered for estimation purposes

G4
Proposals: an example

Proposal #1: FSM (product) unit /(project effort), but gathering at least the split of
project effort data into F vs NF effort

• Functional (product) size: 980 IFPUG FPs
• (project) effort: 1200 man-days as follows:

Req. Type Effort (m/d) Effort (%)
F 850 70.8
Q 100 8.3
T 150 12.5
O 100 8.3
Total 1200 100.0

• Productivity: 980 FP / 1200 m-d = 0.82 FP/m-d
• Functional productivity: 980 FP / 850 m-d = 1.15 FP / m-d


G4

Proposal #2: F/Q/T/O (product) unit /(F/Q/T/O effort): more productivity figures
per effort type

• Same hypothesis than before, but having other size units for the Q/T/O parts it
will be possible to calculate separately other productivity figures in parallel
 Q productivity, T productivity, O productivity
Req. Type Effort (m/d) Effort (%)
F 850 70.8
Q 100 8.3
T 150 12.5
O 100 8.3
Total 1200 100.0

• Advantages for planning (effort/cost; a tester does not cost and does not work
the same worked time as a project manager) and scheduling (the right role for
the right effort)  use both mean and median values


G4

Proposal #3: (project) unit /(project effort): one overall productivity figures for the
whole project, using a unique project size unit

• Same hypothesis than before, but having a unique size unit for the whole project
it will be possible to calculate a high-level, overall productivity figure, to use
jointly with detailed figure
• (project) size: 1450 project size units
• (project) effort: 1200 man-days
• Project productivity: 1450 project size units / 1200 m-d = 1.21 FP / m-d

• Up to day, PMBOK introduces the ‘project size’ term but it is neither defined into
in its glossary, nor any suggestion about specific applications/techniques
• Issue to be investigated more (PSU – Project Size Unit - is a possible proposal)


Conclusions…

• A software system is one of the work products from a software
project; the size units for each entity should be properly used
accordingly to the entity and a certain informative goal.
 a FSU is a product, not a project size unit

• FSM methods pertain only to the functional side of a software
system and do not measure the whole system  productivity levels
should discriminate the possible different parts composing a project
 ISO/IEC 14143-1 proposed the F/Q/T requirements taxonomy; a fourth group can
be added (“O”ther requirements), referring to those implicit but within the project
scope

• Look at the project as composed by several sizes…
 The functional size is just one of these; other possible ones can be explored more
and more in order to have the right picture on the reality to be represented

• …producing therefore several possible productivity values
 Having a bird’s-eye-view on the project and crossing the functional size with the
other possible ones will help the project manager in executing a better and more
granular control, simply having more info from the same base of project data


…& Prospects

• Focus more on the measurement of non-functional perspectives
 i.e. IFPUG is going to propose by the end of 2008 its proposal for “Technical
Points”, with an overview presented last week in Washington at ISMA 2008
 This proposal was done last year at ISBSG Workshop and main concepts could be
included in the next “Practical Project Estimation” guide (3°ed.) in 2009.

• Start to introduce a further effort data into project repositories
 Split (even roughly) effort values into Functional Effort and Non-Functional Effort
 It will help to have in your organization

• Gather more evidences about this view…
 If you have more evidences, please share them: the white paper “
Some thoughts on Productivity in ICT Projects” is a living document, updated
periodically when new evidences are available and can be shared within the
Software Engineering community, on forums and mailing list
 A mailing list in Spanish is [calidaddelsoftware]

• …producing therefore several possible productivity values
 Now it’s time to refine our project data gathering at least on effort data, producing
not only a ‘nominal’ productivity value, but also a separated ‘functional’
productivity value and use the two for better estimates


Q&A

¡Gracias por la atención!
atención
Thanks for your attention!
attention

LuigiBuglione Engineering.it S.p.A.
t +39 06 83074472 Via Riccardo Morandi, 32
m +39 335 1214813 I-00148 Rome (Italy)
luigi.buglione@eng.it www.eng-it.it

www.eng.it WSPM/SGPS 2008 – Luigi Buglione © 2008

Some thoughts on Productivity in ICT Projects: measurable entities, requirements, possible impacts

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Some thoughts on Productivity in ICT Projects: measurable entities, requirements, possible impacts

Semelhante a Some thoughts on Productivity in ICT Projects: measurable entities, requirements, possible impacts (20)

Mais de Luigi Buglione

Mais de Luigi Buglione (20)

Some thoughts on Productivity in ICT Projects: measurable entities, requirements, possible impacts