|
-
:
Project Size Units (PSU) was originated in 2003 to provide a possible answer to this exigency, with the further constraint to do not modify initially the usual way for many project managers to estimate by experience and analogy but moving them progressively towards a more statistical-based way (regression analysis) for making their project estimations. PSU can be defined as a project management technique that allow a Project Manager to associate an early sizing measure to the estimated effort, using a calculation mechanism very close to the FPA one. The entity to be counted and analysed is the “task” derived from the initial project WBS at the bidding phase.
Next table proposes the commonalities and differences between PSU and FPA:
|
Method
\ Elements |
Entity |
Complexity |
Adj.
Factor |
Complexity |
|
FPA (standard) |
Data (ILF, EIF) and
Transactions (EI, EO, EQ) related to the functional requirement for a
software system |
3 levels (H/M/L) for each
type of entity. |
14 General System
Characteristics (GSC) |
Weight (0-5) for each one
of the 14 GSCs, with a ±35% variability on the value of
unadjusted FPs |
|
PSU (early) |
Detailed (functional) UR
and derived tasks (rule: 1 task = max x m/d) for the technical
phases of the SLC. |
3 levels (H/M/L) for each
detailed UR referring to the number of detailed tasks per UR (and therefore
of m/d, statistically derived). |
% weighting for
evaluating the amount of effort needed in poportion for management and
qualitative tasks. |
This percentage is
derived from the analysis of the historical project database and it is
proportional to the number of unadjusted PSUs. |
Next table proposes a more general comparison between early sizing methods (such as PSU) and full sizing methods (such as FPA):
|
|
Early
methods (PSU) |
Standard
methods (FPA) |
|
SLC phase to be applied |
Planning (level L-1) |
Design (level L-2) |
|
Accuracy level |
Lower than standard
methods (avg) |
Greater than “early”
methods (avg) |
|
Control parameters for verifying the
estimation accuracy |
In both cases, MRE and Pred(0.25) values calculated on the estimated
effort must be compared with those calculated at the end of the project and
the MMRE and Pred(0.25) on the entire set of projects included in the
historical project database used for the forecasting system. |
|
|
Information level needed |
Documentation from the
Bid phase |
Documentation from the
Analysis phase |
|
Requested skills for estimation |
Project team |
Function Points
Counter (preferably a CFPS) |
|
Time needed for estimation |
0.5 m/d (per PSU counting) |
1.5-2 m/d (per FPA
counting for medium-size projects) |
|
Strengths |
· Quick calculation · Not requested FPA knowledge · Project estimation can be done before the
Analysis & Design phase |
·Greater accuracy in the
size calculation to be used for the estimation ·External comparability of
results |
|
Weaknesses |
·Lower accuracy in the
size calculation to be used for estimation, verification of correlation with
“standard” techniques ·Internal Comparability of
results |
·Greater effort for
deriving the number of FPs ·Requested the knowledge
of FPA ·Project Estimation can be
done before starting the Developing phase (Coding) |
|
Comments |
Experimental & Internal technique |
Consolidated and diffused
technique, with counting rules regularly monitored by International bodies. |
Differently from a 1st generation FSMM (IFPUG, NESMA, Mark-II, …), PSU has its own weighting system that evolves during time, with a periodical updating based on your own historical project data. This allows to obtain a final result in terms of number of sizing units closer and closer to the real project complexity, assuming a greater relevance when referred to data comparability across time. Weights revision is periodically performed (at least twice a year), as well as the possible modification of the number of complexity levels currently determined. This determines that historical series of PSU values can be used only for internal benchmarks, but with a great advantage in terms of effort for calculation and ease of calculation rules.
PSU and FSMM: friends or foes? :
Use of PSU is not necessarily exclusive: indeed, it can be used for the project only in Bid or in the Planning phase, moving to a standard method such as FPA in following phases, up to project closing. Furthermore, PSU can be used as the main measure, and FPA as a control measure, verifying alignment during project life by relating estimated and actual values of project size.
This article (in Italian) proposes the way to use jointly the two kind of sizing measures.
PSU Measurement Manual (MM) :
A Measurement Manual (MM) is available for a free download (see in the "Publication" section), containing the rationale for PSU, the counting procedure with examples as well as tips for using PSU for estimation purposes and conversions.
Please, send all comments/feedbacks at my email address
Current version of the Manual is 1.21 available in the following languages: English, Spanish/Castellano and Italian).
Main changes are about:
* improved calculation rule
* how to set up PSU values and weights for your Organization
* how to use PSU with Agile Projects
If you are interested in translating it in another language, please contact me and it will be redistributed through this webpage with your credits.
PSU and Agile Methodologies :
PSU refers to the "project" entity, whatever the SLC adopted. Thus, it can be used also with Agile Methodologies such as XP, Scrum, and other more, proposing a possible solution to some common problem that's the way Estimation is treated in such methods.
Please, take a look at the new Measurement Manual version 1.2, Section 4.10, with a detail about how to apply the general PSU calculation rule to such kind of projects.
Templates :
Click here for downloading a template for a quick PSU calculation.
If you are interested in Agile Methodologies, here you can download a PSU template for Scrum (or other SLC with more iterations)
FAQ - Frequently Asked Questions
Publications / Related Publications
:
What is PSU?
PSU is a project management technique that allows to associate to the project effort estimated by experience/analogy a size. It can be used yet from the Bid phase, because its main inputs are the initial Customer requirements and the first planning and related WBS by the Project Manager, to be refined during next SLC phases. Thus, it can be identified as an "early sizing" technique.
The iterative use of PSU, combined with Project Management best practices and guidelines, can help the Estimator in improving and detailing at the right level the project WBS, with a proper balance betweent the SLC phases and tasks typologies. The data gathering from past projects into a Project Historical Database (PHD) of both PSU (as the project size measure) and the related effort will allow to estimate next projects using also regression analysis (to be included in what PMBOK2004, Chapter 6.4 calls "quantitative techniques").
Is PSU compatible with FPA and other FSMMs? If yes, how?
Yes. PSU can be used jointly with other FSMMs, because a FSMM can be applied from the Design phase on and not before, using as main input Software Requirement Specifications (SRS) while PSU from the Bid phase on. If an organization applies both (PSU and i.e. FPA), browsing its Project Historical Database (PHD), it could be possible to establish a relationship between the two measures and estimate the approximated number of FSM units (i.e. Function Points for FPA or Cfsu for COSMIC-FFP) through the initial PSU calculation in the Bid phase, where a FSMM calculation could be possible but only for those companies that perform an analysis at the same level of depth than in the Design phase.
Can PSU be a perfect substitute for a FSMM?
It depends. A FSMM measures only the functional side of a software project, starting from functional user requirements (FUR).
On the other side, PSU has been created for providing a size for different possible entities: the whole project (PSUp), as well as only the functional part of the project (PSUf), as for a FSMM, allowing a direct comparability. Because of the elementary entity to be measured is the "task", it is also possible to size a "service project": in this case, in the PHD the sizing unit will be labeled (PSUp).
When it is suggested along the SLC to gather PSU in the project?
It is suggested to measure PSUs in three moments: firstly, at the Bid phase; secondly, at the Design phase; finally, at the project closure. The second and third moment are the same for applying FSMMs, allowing the Measurer to compare values among the different methods for establishing convertibility ratios, where appropriate.
Which project documentation is needed?
For new projects, it is sufficient to have the project WBS and estimation assumptions. For closed projects, it will help also to consult the different Plans produced (Project, Quality, Configuration, ...) for extracting possible useful information.
Is it possible to a backfiring calculation from closed project?
Yes. Taking into account the last WBS for a project, the Project Manager can use the same PSU calculation template, considering the eventual decomposition of the tasks (aimed to reduce tasks complexity) in the same way as he/she was drawing the first draft WBS in the Bid phase.
How is it possible to use PSU for effort estimation?
Yes, but the usual way to run regression analysis will represent a "tuning" of the initial effort estimation obtained during the PSU calculation through a comparison with historical data from your Project Historical Database (PHD).
Why quality & mangement (QM) tasks are managed as an "adjustment factor" and not taken into account as well as the technical (T) tasks?
There is a huge habit to underestimate the amount and effort devoted to QM tasks. If those tasks would be managed as well as the technical ones, their contribution will be proportional and quite low. One of PSU goals is to provide - according to each organizational policy - indications about the minimum amount of effort devoted to those tasks and related processes ("secondary" or "support" ones), educating estimators to do not forget to include also these kind of tasks in their plans.
Can be PSU calculated by a Project Management tool?
Yes, it can. Because the entity to work on are tasks, it is possible to implement into a PM tool the PSU calculation rules. Right now, there is an open request for a new functionality to add in GanttProject.
If you are interesting in creating a macro for this or other PM tools (e.g. MS-Project, Primavera, etc.), please send me an email! They will be redistributed as free, open-sourced items.
I've produced a list of requirements for automating PSU, available in Italian, English and Spanish.
:
Buglione L., Dimensionare il software: qual è il giusto "metro"?, White Paper, Bloom.it - Frammenti di Organizzazione Ottobre 2003
Buglione L., PSU e Metriche Funzionali per il Dimensionamento del Software: concorrenti o alleati?, White Paper, Bloom.it - Frammenti di Organizzazione 14 Marzo 2005
Buglione L., Project Size Unit (PSU) - Measurement Manual, v1.01, October 2005, Available versions: English, Spanish/Castellano (transl. Veronica Rubio Rodriguez), Italiano
Buglione L., Dimensionare i progetti: che "metro" usare? XPM.it, Giugno 2006
Buglione L., Project Size Unit (PSU) - Calculation feature in Project Management tools - Requirements, v1.0, December 2006, Available versions: Italian, English and Spanish
Buglione L., Meglio Agili o Veloci? Alcune riflessioni sulle stime nei progetti XP, XPM.it, Febbraio 2007
Buglione L., Project Size Unit (PSU) - Measurement Manual, v1.2, August 2007, Available versions: English, Spanish/Castellano,
Buglione L., Project Size Unit (PSU) - Measurement Manual, v1.21, November 2007, Available versions: English, Spanish/Castellano, Italiano
Racheva Z., Daneva M., Buglione L., Complementing Measurements and Real Options Concepts to Support Inter-iteration Decision-Making in Agile Projects, 34th Euromicro/SEAA 2008, Workshop on Software Management, Parma (Italy), 3-5 September 2008
Racheva Z., Daneva M., Buglione L., Supporting the Dynamic Reprioritization of Requirements in Agile Development of Software Products, IWSPM 2008 , International Workshop on Software Product Management, Barcelona (Spain), 9 September 2008
Buglione L., Cuadrado-Gallego J.J. & Rejas-Muslera R.J., Project Size and Estimating: A Case Study using PSU, IFPUG and COSMIC, Proceedings of IWSM/Metrikon/MENSURA 2008, Munich (Germany), November 18-19 2008
Ormandjieva O., Buglione L., Daneva M., Early Prediction of COSMIC size with PSU from User Functional and Nonfunctional Requirements , Proceedings of IWSM/Metrikon/MENSURA 2008, Munich (Germany), November 18-19 2008
Rubio Rodríguez V., Estudio y aplicación de las PSU (Project Size Unit) para la planificación de Proyectos Software, Universidad de Alcalá de Henares, Escuela Técnica Superior de Ingeniería Informática, Ingeniería Técnica En Informática, Especialidad en Gestión, Trabajo de fin de carrera, Madrid, Junio 2007
Fernández Sanz E.D., Estudio Y Evaluación de PSU (Unidad de Medida de Proyectos) Y Estudio Estadístico de La Conversión De Mediciones PSU a Puntos De Función IFPUG, Universidad de Alcalá de Henares, Escuela Técnica Superior de Ingeniería Informática, Ingeniería Técnica En Informática, Especialidad en Gestión, Trabajo de fin de carrera, Madrid, Junio 2007
Biagiotti C., Migliorare gli aspetti di stima e pianificazione di un progetto attraverso la customizzazione di un toll OpenSource di Project Management, Università di Perugia, Dipartimento di Ingegneria Elettronica e dell'Informazione, Tesi di Laurea, Perugia, Luglio 2007
[QEST & LIME models]
[Presentations]
[Links]
