Finding it difficult to put together fixed price contracts under your existing IT procurement guidelines as you move to an Agile approach to software development? Well, you’re not alone.
The most common contract approach for technology projects that follow Agile methodologies is time and materials. But this approach results in the client carrying all the commercial risk and often is frowned upon by procurement professionals and executives, due to its potential for cost overruns.
The generally accepted approach for low risk procurement of complex systems by organisations, that do not have large development resources inhouse, is to engage a system integrator using a fixed price contract (or lump sum).
This is the preferred approach because many delivery risks are outsourced to the integrator by the client and it uses the integrator’s project management disciplines. Finances are also better aligned with the business case process (i.e, the funds available can be matched with the fixed price contracted amount at the commencement of the contract.)
However, the difficulty with fixed price contracts is that they invariably require the client to define the technology solution to level of detail sufficient for the integrator to adequately price the whole scope of works at the time of bidding.
This always requires more detail than is available at the commencement of an “Agile” project.
What is Agile?
Before I go any further I need to define what I mean by an Agile development methodology. According to Wikipedia, it’s a software development approach that uses adaptive planning, evolutionary development, early delivery, and continuous improvement, and it encourages rapid and flexible response to change. This is a good high-level summary that embraces the Agile Manifesto.
As discussed earlier government and some large corporates typically procure the external resource component for their “Agile” team using time-and-materials contracts. This approach results in them taking the delivery risk but it has the commercial flexibility to allow a government client to deliver systems using an Agile approach.
Conversely, government procurement rules presuppose a waterfall approach and require fixed priced contracts to be retendered after detailed design and for the delivery phase of a project. This is done to ensure the incumbent design phase contractor is not unduly favoured by just giving them the delivery phase project.
Function points and project estimates
One solution to overcome the need to retender for delivery and to provide better budget estimates is to use function points coupled with a project costing database.
A function point is a unit of measurement to express the amount of business functionality an information system as a product provides to a user. Function points are used to compute a functional size measurement of software.
A Function point counting standard has been created by International Function Point Users Group (IFPUG). This group has standardised both the counting of business functionality with the Function Point Counting Practices Manual, and an evolving industry standard using the Software Non-functional Assessment Process.
Additionally, the cost (in dollars or hours) of a single unit can be estimated from past projects to allow an estimate of the total projects cost from function point counts of user requirements or functionally decomposed scoping documentation.
A good source of estimate information is the International Software Benchmarking Standards Group (ISBSG) database. ISBSG is a not-for-profit organisation that provides a database of project costs based on function point counts and other project parameters.
At the business case and tendering stage of the project it is not important that some functions used to create the estimates are not valid. At this stage of the project, the important issue is that the size of the project and its complexity is accurate to about + or – 20 per cent. This is the contract tolerance for the tendered function points and ensures there is enough flexibility in the contract to deliver a viable system.
Also, the non-functional requirements for the system need to be known at a high level to ensure the correct example estimates are selected from the benchmark database or additional fixed price costs added. Many of the non-functional requirements are covered in the benchmark database. A typical list of non-functional requirements for a project is shown below.
Some of these will be covered in the benchmark database but some will need to be added as extras in the request for tender document and separately priced.
Environment – the development environment and target production environment
Performance – response times for various functions
Code quality – the defect level of code and applicable standards
Security – security strategy and level should be defined this if often an enterprise document which is already available
Privacy – identification of PII and related data and the laws and standards for which compliance will be required
Accessibility – the standards and level of compliance
Availability – the mean recovery times and associated design implications also whether system operates 24x7 or is more 8x5
Reliability – the level of auto replication and redundancy before failure
Supportability – the level of documentation and other knowledge transfer requirements
Records Management – record keeping standards required
Auditable – documentation and audit trails and logs required
Documentation and Training – required to use and operate the system.
Tendering with function points
When organisations need to engage third party system integrators to deliver systems they need to ensure that the processes they use are fair and competitive.
The objective is for the client to get the best value for money solution with the final delivery to be of high quality and delivered as quickly as possible satisfying the client’s needs with the least risk.
Fixed price tenders struggle to achieve all the above objectives. They are difficult to price hence often have a premium for risk. They also often fail to satisfy client’s ultimate needs because the requirements have to be defined right up front in the business case and tender documents.
On the other hand, a tender which requires a tenderer to bid based on function points is more likely to deliver a system which will satisfy client needs and represent good value for money, as the tenderer is providing a price per function point for a system of a certain size and type not a price for a completed system with functionality defined at the time of bidding.
To achieve a price per function point, the tenderer will need to be provided the high-level functional model used to price the project and a statement of the non-functional requirements. The tenderer will then provide a price per function point for the system based on size and complexity not detailed functions, and a fixed price for any non-functional requirements not covered by the function point count model.
The evaluation of tender responses therefore will be evaluated on the price per function point multiplied by the total function points provided in the tender plus any other tendered amounts for non-functional deliverables.
These figures when totalled will form the basis for the comparative value for money analysis used in tenderer selection. Value for money is often determined by factoring the non-price evaluation criteria (experience, quality, methodology, etc) against the financial cost of the project.
The contract formed from the above tender process is in fact a mixture of a ‘schedule of rates’ for function points delivered and fixed price for selected non-functional requirements.
Managing function point contracts
The management of function point contracts is not different to managing any time and material contract except that the contractor is paid on delivered function points not hours of effort expended.
This requires the system to have ‘as built’ documentation created at the completion of the project and counted by both the contractor’s and client’s function point counters.
They need to agree the number of function points delivered. Amazingly this is a far less combative situation than I have experienced when arguing about the cost of variations in a fixed price contract.
Once this agreement is reached then the contractor can be paid an amount equal to the contracted price per function point times the number of function points they actually deliver.
There may be other payments for agreed fixed price items within the contract such as the cost of delivering a hardware environment, but the main cost will nearly always be the cost of delivering the software.
The advantage of the above approach is that the contractor and client can develop the detail of the system using Agile methodologies during the build and then use the ‘as built’ documentation for both costing and testing the system.
The documentation can also be used to prove the system delivered by the contractor satisfies the contract and hopefully the original business case, although in many cases the organisation has moved on since the business case was developed.
It is important to note that Agile projects need strong governance as they will by their nature evolve and it is important that the project evolves in the direction defined by the steering committee. It is unlikely that the end deliverable will be exactly like that envisaged in the business case, but that is ok, as long as the deliverable changes have been approved by a process which management is confident gives them the best outcome.
In response to the question posed in the title, the use of function points does not give a true fixed price contract – but gets pretty close. The contract you wind up with is more a mixed fixed price/schedule of rates contract.
It is fair to say however the contract has the price “boxed” to a known amount at the time of tenderer selection, which can easily be related to the funding allocated. The main advantages are the project can be delivered quickly using Agile rather than the delays associated with traditional Waterfall methodologies.
Also, compared to time and materials contracts where you still pay even if nothing is ever delivered, costs can be controlled by managing the number of features delivered. This way, you at least get a working deliverable for your money and if the governance is right then it should be a deliverable which satisfies your organisations current needs.
The above approach should be something the Prime Minister’s ICT Procurement Taskforce consider in their review. I would suggest that the above approach could be used within current procurement rules. However if this is to happen agencies will have to improve their contract management and ICT governance capability in relation to the tendering, formation and management of ICT contracts. Hopefully this will improve in the future.
I have used the above approach on several projects with great success and would encourage anyone with suitable projects to do the same. Please feel free to contact me if you want more information.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.