It’s all about satisfied customers

There is a lot distracting us from what it is all about: satisfied customers. For instance the choice whether to use agile scrum or waterfall as development environment, think of organization moves or commercial interests.
In the end most important is the required functionality!  Functionality that supports processes in a satisfactorily way enabling  customers to achieve goals. In recent years we have experienced that Function Point Analysis Indicative (FPA_i) in the early fases  of software development acts as a good catalyst in keeping focussed on customer functionality.

The IP(Information Provision) chain of the Dutch Tax and Customs Administration consists of  a demand and a supply side. Demand represents the internal customers; supply realizes IT provisions. In 2013 an FPA_i pilot on demand was run. This pilot was originated by the need of demand to have its own early applicable and objective method for estimating costs. Another need was to improve substantiating the choices in the long-term portfolio. In the long-term portfolio all changes of (parts of) information systems in portfolio items have been included. Within the organization we have to make well-founded choices between these portfolio items, because we have to work with generally decreasing yearly budgets.

FPA_i  is supplementary to the traditional FPA measurement already succesfully performed by supply for many years.The result is also is a functional size expressed in function points. It goes without saying that in those early stages of development, dynamics and uncertainty are greater than during realization.

In line with the NESMA publication on the application of Function Point Analysis in the early phases of the application life cycle demand applies four tracks of sizing: 1a, 1b, 2a, 2b. See the plan below of The structure of FPA_i. Which track we follow depends on the phase of the preliminary stage the portfolio item finds itself in. The more we progress in time -from left to right- the more (detailed) information on the portfolio item becomes available.

Different tracks to the right size

As long as the portfolio item finds itself in the concept phase and we are still many months away from realization, the result in function points is approached on the basis of analogy (track 1a). This requires the availability of system or product counts of similar, already realized portfolio items. Potentially to this system count an FPA_i validated delta (+ or -) size count is added. In this way a first size is achieved in a short period of time.

The moment a set of needs and requirements,  a description of the desired situation or a first product backlog is available, a workshop is organised  in which various experts -facilitated by us-  count the user functions leading up to function points (track 1b).

If a first data model becomes available, for instance an object model, we may execute the next recalibration (track 2a). With the availability of information on the processes, we will be even better able to approach the size (track 2b)!

To reduce the uncertainty of the sizing results, thus increasing reliability, consistency and traceability are important aspects during the evolution of a requirement. In practice: A requirement to register entrepreneurs is determined  and valued during an FPA_i session with experts on track 1b. This leads to an indication of function points and an outline of the costs. At a later moment in time on track 2a, one expects  to encounter a logical data file to be able to register entrepreneurs data. Next recalibration makes it logical to discover the entrepreneurs registration processes entering, changing and deleting. Should this not be the case, questions will be asked. In this we see an extra spin off of FPA_i and a win for the designers and developers: quality improvement.

Of course, the organization is often interested in the extend to which IT costs – deduced from function points- may be linked to such aspects as goals, releases, work packages, epics, backlog items or (MoSCoW- method based) prioritizations. Other frequently asked profiles are categorization to design work, connecting work and configurating work. Or insight into the functional size intended to be realized by means of building blocks, packages, outsourced or custom-made software. We are able to offer any such profiles. However, FPA-analysts are no wizards! The source information describing the functionality linked to the aspects mentioned above, needs to be available; either in documented form or in the minds of experts who we may interrogate. Should this information become available at a later moment, we can include it in a recalibration and at that moment provide the organization with these insights.

Demand cooperates with supply.  We compare function point counts of the preliminary stage with counts at the beginning and the end of realization. The learning circle of sizing during the IP-chain has shown that certain corrections have to be applied in the preliminary stage. Amongst other things, our FPA_i reports take into account the following effects:

• Scope creep, a correction we may apply dependently on the dynamics to be expected in the functionality (more or less work). From the portfolio perspective we aim to limit this as much as possible.
• Autonomous growth, an addition, depending on the level of detail of the expected functionality the source can provide us with in that early phase. A further elaboration in time, often reveals extra functionalities.
• Phased in production, a positive correction connected to the realization in various releases. The fact is, that working at software modules several times all over again, takes more time than having the opportunity to finish the work consecutively.

Sizing function points has now been done by us in the preliminary stage during a few years. Experiences are:

• FPA_i is the objective means to enable continuous (costs)recalibrations, to improve transparency and to support the portfolio-function to make relatively fast long-term portfolio choices and priorizations in conjunction with other portfolios.
• The method is also excellently suited to investigate if “we get value for money” and to take measures if necessary. Realizing planned functionalities within a certain period of time is preceded by a cost claim based on function points. This claim is fully or partly honoured by the allocation of budget. Of course it is quite valuable to analyse at the end of the period of realization, if what was asked for, really has been delivered! And should this not be the case, to assist in determining the consequences and defining actions. Function points may very well be used for these purposes too.
• IT realization costs are determined by two factors only: on one hand the size (expressed in function points); on the other the realized productivity (expressed in cost or hours per function point). In spite of this clarity, it often proves difficult to point out this distinction to experts. The size factor is exclusively concerned with the desired customer functionality, the number of user functions. Functional sizing have nothing whatsoever to do with the complexity of producing certain functionality, the necessity of including many controls or technical tables containing a large variety of data, millions of messages to be processed or development in an agile scrum way. They have everything to do with productivity!

FPA_i contributes to executing our customer representative rol in a professional way. In cooperation with supply, the FPA_i method supports our ability to determine a common view of the cost of portfolio items. In the tendering process, negotiations aimed at controlling costs may take place.

FPA_i is a relatively simple estimation means -by itself a great merit in the complex world we find ourselves in- putting first and foremost the functionality asked for by customers. It supports software manufacturing organizations to be better able to substantiate portfolio choices, to make objective cost estimations and to link those to such aspects as releases or work packages. It may also determine whether the functionality which is expected by the customer is really delivered or not

FPA_i; for software manufacturing organizations the second best cost estimation and analyzing method! The best one still has to be invented.

 

About the authors:

Margreet Renshof is tactical architect. Herman Buitenhuis is tactical consultant. Both are working for the Portfolio management department of Tax Information Management Directorate of the Dutch Tax and Customs Administration.

A blog post represents the personal opinion of the authors
and may not necessarily coincide with official Nesma policies.