Chapter 6

Software Project Pricing

6.1 From Cost to Pricing

Project pricing is how much we charge the client for a project. As excellently pointed out by Sommerville (2007), there is no simple relationship between cost and pricing, since broad organizational, contractual, political, and business considerations influence the price charged.

To understand better some pricing strategies for software products, a good starting point is to look at a product life cycle and understand what are the sources of costs and revenues for a software system. This is shown in Figure 6.1, where we distinguish four different phases:

1. Inception (or feasibility) is the phase during which an organization analyzes the opportunities and risks related to the development of a new software system and authorizes its development. In some cases, the process is initiated internally. This is the case of products that will be sold or deployed internally to improve the organization’s efficiency or capabilities. In other cases, the process is initiated externally. This happens, for instance, if a prospective customer asks for the development of a one-off software system or specific services related to a product of the performing organization. The activity is organized as one or more projects, using the project selection techniques we have seen in Section 3.1.
2. Development is where the actual development of the software system takes place. Software development is organized with one or more projects, as illustrated in the previous chapters.
3. Operation and maintenance is where the system is used and updated to meet old requirements, which were implemented wrong, and new requirements coming from changed conditions in the operations or business environment.
4. Divestment is the phase during which a system is retired. Divestment costs might be significant; consider the case of stopping a nuclear power station. For software systems, however, the situation is rather different and the costs related to the divestment of a software system are mainly related to migrating the application data to a new operating environment.

All phases of the process mentioned above are a source of costs for an organization. They are also a form of investment and a source of revenue, according to the project goals and the destination of the product being developed. To exemplify, let us consider two different scenarios.

The first is a situation in which a software house decides to develop a new product to be sold to users. Inception and development of the system is an investment; during these phases, in fact, the software house will be spending money without getting any revenue for the work being performed. During operations, the situation is partly reversed: money will start flowing in from selling the software. For business to make sense, the revenues should sustain the operational costs (e.g., maintenance and support), cover the inception and development costs of the system built (or the inception and development of a new system), and allow for some profit.

The second is a situation in which a customer requires services for the development of a one-off system. We can take two different points of view, that of the customer and that of the contractor. From the customer’s point of view, inception and feasibility are a cost; the first may be as an internal investment (e.g., to evaluate the benefits of the system); the second may be in the form of services requested of the contractor. During operations, the client will save money or possibly make more money by using the system developed. When the system is retired, the customer will bear the expenses. The contractor is in the opposite situation. Inception and development will be a source of profit. During operations, various situations occur. The contractor might incur unexpected expenses if a low-quality delivery, for instance, requires extensive corrective maintenance. Conversely, the contractor could incur additional revenues if the client asks for new functions to be added to the system.

The scenarios above are quite common and apply to different kinds of projects and products, not necessarily software systems. Software and the characteristics of the software business, however, introduce novel possibilities in the arrangements between the client and the supplier.

Software, like any other digital good, is extremely cheap to reproduce: thus, most of the costs related to the software business are for the production of the first copy. Software is also cheap to distribute through the Internet. This, and the fact that the software industry is more internationalized than any other sector, fuels a global competition like no other (Bruxam et al., 2013).

This chapter introduces some basic concepts about project and product pricing. It is a vast subject, whose surface we can only scratch. Here, we will look at some of the basic principles and concepts.

6.2 Software Pricing

6.2.1 Software Pricing Models

According to Bruxam et al. (2013), there are three ways to determine the price of software:

1. Based on cost
2. Based on value
3. Based on competition.

Cost-based pricing determines a project price based on the costs. Costs related to software, as we have seen, include production and distribution. Production costs can be estimated using the techniques we have seen in Section 3.4 or, more simply, accounted for once a system is production-ready. Operating costs include distribution, maintenance, and customer support and are sometimes underestimated.

Things are not so clear-cut, though. To provoke the reader, Davidson (2012) suggests that production costs are sunk costs, that is, money already spent and therefore unrecoverable. Thus, according to the author, only operating costs should be part of the pricing equation. We elaborate a bit and say that cost-based pricing should at least cover the operating costs; otherwise, it would not even make sense to distribute a software system. Cost-based pricing should thus carefully analyze what are operating costs, which are often hidden; consider the time spent on customer support. If we want our business to grow, on top of that, cost-based pricing should allow a sufficient profit to pay for the development of new systems.

Value-based pricing determines the cost based on how much the customer is willing to pay. This allows one to define a pricing strategy more flexibly, since it is based on the perceived value of a system. The perceived value can be changed in different ways. For instance, Davidson (2012) suggests using the company’s reputation, offering a better service, and creating a community or a sentiment behind a specific brand or product.

Finally, competition-based pricing determines the cost based on how much the competition is charging for a similar system.

6.2.2 Selling and Licensing Software

Ownership is another important factor in determining the value and the price of a software system.

In principle, three possible schemas are applicable: licensing, leasing, and selling.

When a company licenses a software system, it grants the right to use the software to a customer, while retaining the ownership. The license is usually sold and the money made with the licenses is used to pay for the development and maintenance costs, as described above.

Licenses are sold in different ways. The most common is selling by the copy. Larger organizations often benefit from bulk purchases, with which they buy, at a discount, the right to use multiple instances of the software. Bulk purchases, in turn, can be by user, by seat, or by instance, according to whether the number is bound to the people who have the right to use the system, to the computers on which the software can be run, or to the maximum number of instances that can run at any given time.

Leasing is another schema in which the right to use the software is sold for a limited period. Users need to renew their licenses on a regular basis. Similar to many other markets, in some cases, the entry cost is set low to reduce the barrier to entrance. Leasing is very popular with web applications, since access to a system is directly controlled by the company leasing the software, which can grant it or revoke it as needed. Some desktop applications also use or offer a leasing mechanism. This, however, requires specific protections to be in place, so that the software does not run if the lease has expired.

With respect to the previous model, leasing has some advantages both for the client and the seller. The first, in fact, can get the product at a lower entry cost. The second has a revenue model that guarantees more steady revenues.

Finally, software can be sold. Although this is seldom (if ever) the case for off-the-shelf software, for one-offs, the client might be interested in taking ownership of a system.

6.2.3 Open Source Software

A very peculiar type of license is that of open and free software. The concept has its roots in 1983, when Richard Stallman started the GNU project with the goal of building an operating system that would be free for users to use and for developers to collaborate on (GNU Software Foundation, 2013). In the process, he also started a movement that has led to the development of industrial-strength software used by millions of people, such as the Firefox browser, the Linux operating system, the Apache HTTP Server, the LibreOffice office suite, and the Ruby On Rails development framework, to mention a few.

Today, the term free software has a relatively broad meaning, with different rights and obligations for users. Some free licenses simply allow one to use an application without paying any fee. Other approaches, which we call open source software, also make the source code available for anyone to improve and use. Even if we restrict our attention to open source software, more than 60 different licensing schemas are available Open Source Initiative (2013). Of these, according to Open Source Resource Center (2012), two of the most popular are the GNU General Public License and the MIT License. The former protects original and any derivative work, which has to be made available under the same license (Free Software Foundation, 2007). The latter is a very liberal schema that allows the software to be reused and relicensed as one wishes (MIT, 2013).

There are different motivations for developing a system using an open source license. Ideals are the main driver of many like Stallman. Others use it as a way to build a critical mass and foster the development of applications for which there are not enough resources. This is the case, for instance, of Netscape, which released the source code of its browser, Netscape Navigator, as an attempt to resist the increasing pressure set by Microsoft with Internet Explorer (Kornblum, 1998; Lewis, 1995).

Open source software can also be a source of revenue. The main models include

• Donation and gadgets
• Service providing
• Advertisement
• Market segmentation and freemium services.

Various organizations behind the development of open source systems base their revenue on donations or by selling gadgets, such as T-shirts or mugs. This is the case, for instance, of Mozilla and the GNU Software Foundation.

Another way to make a living out of open software is by selling services. RedHat, for instance, distributes a custom version of Linux for free.* The company makes a profit by selling customer support, training, and other services.

Revenues can also come from showing advertisements while the application is running. The schema is used mostly with web applications and with applications for smartphones. In both cases, specific developer kits are available to try and customize the advertisements based on the user characteristics. In some cases, companies also offer an ad-free version at a price, a case of market segmentation.

Various companies offer a base version of a system for free and charge users for additional services. This is an example of market segmentation or freemium services, a contraption of the free and premium words. For instance, Github, a source-code hosting company, offers a freemium service. Similar to the previous case, freemium systems break the barrier to entrance by making it easier for a user to try a new system, switch to it, and eventually pay for the additional services which the platform offers.

We conclude by noting that some for-profit companies developing closed-source software support and profit from open source systems. In a typical scenario, an open source component might be the basis for closed-source extensions. The company licenses the closed-source extensions while making available its contribution to the open source component, on which their system is based. This is done both to fulfill open source licensing obligations and to keep a community working on the open source component. This is the case, for instance, of Apple’s operating system (OSX), whose operating system is partly based on BSD Unix, released under an open source license.

In other situations, the open source component might be made available to foster integration and extensions by a community of volunteers. This is the case, for instance, of Ruby On Rails, a web application framework made available under a very liberal open source license. David Hansson developed the first version of Ruby on Rails, while he was working at 37Signals on BaseCamp, the flagship product of the company. Today, Ruby on Rails is a very popular web applications development framework. Releasing Ruby On Rails in open source fostered the growth of a large community. Thus, additional effort required to make a system open source was richly rewarded by the vibrant community it created and the visibility obtained by the company and its products. Thus, even if the initial release was not motivated by self-interest, it created a win-win situation.

In synthesis, companies and foundations alike support the development of open source software. Projects developing software in open source have produced hundreds of millions of source lines of code and systems as large as 30.7 million source lines of code (Black Duck Software, 2013). It is therefore an opportunity and a model to consider with attention.

*Linux is distributed with the GNU License, which makes the software and any derivative work open source. RedHat could, in principle, sell the software as long as it made available all source code.

6.3 Project Pricing Strategies

In the previous section, we have seen some techniques to determine the price of a software system. On many occasions, however, this can be very difficult or irrelevant.

In these situations, looking at the project costs is a second good strategy. We can take two points of view, that of the client and that of the supplier. Basically, the strategies described in the following sections allocate financial risks between the supplier and the client, trying to find the equilibrium that makes it convenient for both parties to achieve the project goals, given the constraints. Given the fact that the client and the supplier often have different goals, this process is difficult, challenging, and very interesting.

6.3.1 Determining the Project Price

From the supplier’s point of view, given the basic equation:

$\begin{array}{cc}\text{Price}=\text{profit}+\text{costs}& \left(6.1\right)\end{array}$

we can end up with different project pricing strategies, according to which one of the elements we fix in the equation (Maylor, 2010).

We can fix the price. Setting the price of a project to how much a client is willing to pay, for instance, can be an effective way to get a contract. The strategy, called pricing to win, however, constrains every other project aspect around the price. Risks include the possibility of not making any profit or delivering at a loss. If the price is set too low, another risk is compromising the quality or the delivery of the project outputs.

To mitigate the problems above, a target costing strategy can be put in place. According to this strategy, both price and profit are determined. The first is based on a value that makes the project competitive, the second according to the desired margin of profit. The costs are then met by elaborating on the other project constraints. The management, for instance, can evaluate different implementations; it can make project activities more efficient, or it can push the cost constraints to suppliers of project components.

The technique, applied systematically by Japanese companies, is today popular in the aerospace and automotive fields (Maylor, 2010). See Feil et al. (2004) for a nice historical overview.

An alternative schema fixes the profit and determines the price based on the actual costs incurred on a project. The profit is typically in the form of a percentage of the actual costs. The schema increases the probability of achieving the time and quality goals one desires. However, one risk for the client is that costs spiral out of control. Another consideration is that there are no incentives, from the economic point of view, to deliver efficiently or according to the required quality and schedule.

Finally, it has to be remarked that an organization may deliberately choose to be not profitable in a project to achieve a more strategic goal, such as entering a new market, getting a new important client, and limiting competition from other companies. In these situations, project costs need to be covered internally.

6.3.2 Contractual Agreements

Given the constraints above, we can come with different contractual agreements that try and allocate project risks between the client and the supplier.

Fixed price contract is a kind of agreement where the price is fixed at the beginning of the project for a given set of services or products to be delivered.

For the supplier, this contract requires accurate estimations and sufficient margins to accommodate for changes in the effort and other unexpected expenditures. It suits better projects in which the requirements are very clear. The client will end up paying an extra price (the margin imposed by the vendor to accommodate for unexpected events), but the price will be known before starting the project.

If estimations are inaccurate or the price is set too low, one risk is compromising project deliveries, as explained above. As pointed out in Wysocki (2011), “all potential suppliers might agree on a fixed price, but this could be a way to just get in the door and work the details later.”

In specific cases, for instance, if the requirements volatility becomes unexpectedly high, additional agreements might be set to deal with unforeseen expenses. A “cost-plus” contract, however, might be more appropriate if the risks are known in advance—see below.

Time and materials is a kind of agreement in which the supplier exposes the costs to the client and bills according to the actual costs incurred. It requires the vendor to track the activities and actual time spent on the project. An additional effort might be required to check the eligibility of expenses, some of which might not be covered by specific agreements.

An initial estimation can be set to give a rough estimation of the project costs. The contractual agreement, however, corresponds to the fixed profit pricing strategy, since additional expenses are covered for, if the initial estimations are not met.

The agreement works well in situations with a high uncertainty or volatility of requirements, since it shares the project risks between the two contracting parties.

Retainer is a kind of contract in which a fixed price is paid to the vendor in exchange for a fixed amount of time provided.

It is equivalent to renting manpower to achieve a specific goal and, similar to the time and materials agreement, it works better when the requirements are not clear and have a high variability.

Finally, cost plus is a kind of agreement in which the buyer pays a contractor for all the allowed expenses up to a set limit. An additional payment is foreseen to allow the contractor to make a profit if certain conditions are met.

This kind of agreement is applied by government agencies for larger projects when it is difficult to come out with a price and the project execution risk is shared between the buyer and the vendor.

There are various kind of cost-plus agreements, among which we mention

• Award-fee contracts, if the additional payment is bound to the final quality of the product.
• Incentive-fee contracts, if the additional payment is bound to contracts that meet or exceed the performances. Incentive fee contracts reward efficiency.
• Fixed-fee contract, if the fee may be adjusted as a result of changes in the work to be performed under the contract. This permits contracting for work that might otherwise present too great a risk to contractors. However, it provides the contractor only a minimum incentive to control costs (Government, 1998).

Cost-plus can be used when efficiency, quality, or improved performances are a desirable feature. Think, for instance, of the U.S. space program.

However, cost control becomes more difficult. Moreover, similar to time and materials, additional bookkeeping is necessary, for example, to verify that all the expenditures exposed by the contractor are eligible.

6.3.3 Contractual Agreements and Project Budget

From the financial point of view, the client and the supplier have contrasting goals in setting a schedule for payments. The client typically would like to pay as late as possible, while the supplier tries to be paid as soon as possible.

A reasonable compromise must be found between the client and the supplier to show a reciprocal commitment, reduce the financial exposure of the supplier, and minimize the risks of the client paying for services or products that will not be delivered.

To demonstrate the balance that needs to be established between the supplier and the client, consider Burke (2006), who discusses the future and past or sunk costs. In economics, only future costs and profits have to be considered when taking a decision. Any decision we take, in fact, will not allow us to change the past: we can make new money, but nice as it would be, we cannot “unspend” the money we have already spent.

Thus, if financial consideration is the only element to decide whether a project has to continue or is better stopped, the supplier has a simple equation: it has to determine how much the project will cost to complete and how much money the project will award at completion. If the amount is positive, then the project is worth continuing; if not, there is no financial reason to continue a project. Thus, the agreement between the client and the supplier should be such that the money awarded at the end of the project is higher than the cost to complete it.

However, if payments are awarded only at project delivery, a significant investment might be required on the supplier side. The required financial exposure might be impossible to bear or the risk of not being paid at the end of the project could be considered too high to actually get started with the work.

Two main types of agreements are achieved to solve the problem above: payments based on deliverables or time billing.

When adopting a payment structure based on deliverables, the client awards the customer a percentage of the total project price on achievement of specific deliverables or an important project milestone.

The actual payments have to be agreed case by case. An approach fixes the payments based on the costs to achieve a milestone. The schema ensures that, in nominal conditions, the costs to complete it are always lower than the money awarded. Moreover, the financial exposure for the supplier is limited, since payments are performed milestone by milestone.

To reduce the risks of the supplier, an advance payment might be requested at project start. This has the advantage of showing the commitment of the client to the project. For software development projects, the advance payment is often between 20% and 30% of the project total budget. A large number of projects require an advance payment on contract signing.

To simplify the process, organizations working in specific sectors standardize both the milestones for which they ask a payment and the payment structure, in the form of a percentage of the total amount charged for the project.

Stack Overflow (2008) and Hunt (2010) describe the payment structures actually used by some software consultants. One of the schemas described there, for instance, requires a 20% advance payment, followed by a 70% payment on software delivery, and a final 10% awarded on project completion.

A second approach, called time billing/reimbursement, requires payments on a regular basis according to the expenses the supplier has actually incurred.

When using this schema, at the end of every reporting period, the supplier bills the client based on the time actually spent on the project and, if allowed by the agreement, for the expenses actually incurred. If the agreement does not include the reimbursement of any expense, the client bills only for the time. In this case, an overhead is added on top of the hourly rates to cover for the other project expenses. See Section 3.7. Additionally, a percentage might be added on top of the invoice as a profit by the organization.

An important aspect characterizing time billing is the required amount of formality. Some public bodies, such as the European Union, require a detailed account and actual proofs of the expenses sustained. In other situations, the level of formality might be lower. The paperwork required for both parties changes a lot.

Finally, in specific cases, an analysis of the cash flow can be used to determine the actual financial needs of a project and, based on that, decide on a payment structure. This is particularly important if the project has to self-sustain financially.

The four diagrams of Figure 6.2 show the impact of different payment structures on the cash flow of a project. The first diagram (Figure 6.2(a)) shows a retainer agreement, in which payments for services to be provided (marked P1, P2, and P3) ensure the project is self-financed. The second diagram (Figure 6.2(b)) shows a time billing agreement, in which regular payments (marked P1, P2, and P3) reimburse for the actual expenses incurred. The project needs a continuous investment from the supplier. The risks are lowered by regular payments that cover the actual costs.

Figure 6.2(c) and (d) show payment structured by milestones. In the first case, shown in Figure 6.2(c), the project is largely self-financed. This is made possible by an advance payment (P1) and a milestone payment (P2) that also cover some future project costs. The last case, shown in Figure 6.2(d), is a project that requires an investment from the supplier, which is nearly covered on payment P1 and finally covered at the end of the project, with payment P2.

6.4 Procurement and Outsourcing

Projects require different competencies and abilities, and often their success is the result of a joint effort of different companies and consultants.

Procurement management is the set of activities to effectively manage vendors and contracts with vendors. It spans different phases of a project life cycle, including planning, execution, and project closing.

The procurement process can be organized in the following four activities:

1. Identify needs, during which the actual procurement needs are made clear.
2. Identify vendors: solicitation, selection, award, during which the most appropriate vendor is individuated. Different approaches can be used. We will have a look at the main ones below.
3. Manage contract execution, during which the project manager will monitor and control the project by ensuring that the procurement activities are proceeding as agreed.
4. Accept final product, during which the product is accepted.

When we outsource we start a (sub)project in which we take the role of the client. The techniques we have seen in the previous chapters therefore help us set up the main activities required for a sound management of the procurement activities.

For instance, the needs identification phase can use the assessment techniques we have seen in Section 3.1. If we need to choose between externalizing some activities or performing them in-house, for instance, we can use a make or buy analysis to analyze the benefits and risks and select the best alternative.

A similar consideration applies to managing contract execution. The monitoring and control techniques we have seen in Chapter 3 help in establishing clear goals and analyzing subcontractors’ performances. One aspect to consider is that visibility over the actual project data of subcontractors might be limited. Thus, it becomes more important to define reporting duties and what metrics and data the subcontractor should make available.

The acceptance of the final product can be conducted using the quality assurance and testing techniques illustrated in Chapter 4.

More interesting are the considerations related to the vendor selection process, which we describe in more detail in the following two sections.

6.4.1 Vendor Solicitation

Vendor solicitation is the process according to which potential vendors are contacted and informed about your business needs.

This is usually done with an invitation to tender. The invitation to tender contains a specification of the products and services to be provided, together with other constraints related to the proposal.

At a minimum, an invitation to tender will include the following:

• A specification of the products or services to be provided. Think of a scope document. Attention should be paid to ensure that the document clearly states the goals and constraints related to the contract, such as, for instance, timing, quality, and costs; required reliability and compliance with standards; type of support to be provided after the contract ends; and management of intellectual property rights.
• Procedure to submit a proposal and the selection criteria that will be used to award the contract. Best price is a selection criterion. Other considerations might be equally important, as we saw when we discussed contractual agreements—Section 6.3.3. The selection criteria are typically required for contracts awarded by public administrations.

Contractors distribute invitations to tender through various channels, such as advertisements in newspapers, websites, mailing lists, and specialized journals; governments make available their tenders in official documents (e.g., Official Gazette); some companies and some websites provide services of collecting tenders by type and sector.

Tenders can either be open, when any subject can participate, or restricted, when only the supplier can be contacted by the buyer to participate in the bidding phase.

In some situations, a direct call or negotiated procedure to a single vendor might also be used. Restricted and direct calls are used when there are specific project concerns. In these cases, the selection process includes only the vendors who satisfy certain constraints, like having adequate or specific technical competencies. Concerns about financial solidity and the capacity to support the delivered solution after the project ends might also be taken into account. The standard bidding procedure for public administrations is the open tender. Restricted or negotiated procedures can be chosen in specific and motivated situations. The risk is, in fact, that of using public money to favor certain contractors.

For open and restricted tenders, once the proposals are collected, the buyer will select a vendor. This is done by evaluating how the different proposals meet the criteria identified. According to the size and procedures in place, a commission might be appointed with the task of evaluating the proposals.

Evaluations often use score matrices (Section 3.1.3.2) to measure the relative merits of each proposal. In this case, the bid with the highest score is awarded the contract. For score matrices to be fair and effective, of course, the criteria have to be defined before any evaluation actually starts. The problem of fairness, of course, remains in the way in which scores are assigned.

Table 6.1 shows a score matrix to evaluate and select different vendors. The example is taken from the criteria used by the European Union to finance a class of research projects (The Secretariat of the African, C. and P.A.G. of States, 2012). In particular, the evaluation proceeds along two main dimensions, the relevance of the proposal (called action in the table) and its design. Four criteria are identified for assessing the relevance of the action; two for its design. Each criterion has a weight of 1 and a maximum score is set for each criterion.

Note that making the evaluation criteria known in advance can help the vendor define a proposal that is more fitting to the needs of the contractor.

For negotiated procedures and for contracts in the private sector, the procedures mentioned above can be simplified.

Once the vendor is selected, a contract is stipulated among the parties. Contracts specify the work to be carried out and the conditions regulating timing and payments. These are usually specified through a technical annex, which describes the work and the project. Additional clauses determine the ownership, liabilities, and intellectual property rights. Laws governing the contract and the procedure for the resolution of disputes complete the required information.

6.4.2 Procurement Timing Activities

Procurement of services and products can be a lengthy matter. Needless to say, sufficient time and resources have to be allocated to ensure that the various activities are carried out by the book.

In general, the schedule should consider

• The preparation of the invitation to tender, during which attention must be paid to ensure that all the relevant requirements (technical, project, and support) are in place, since little (or nothing) can be done to change the terms of the contract, once the invitation is out.
• Sufficient time for potential bidders to become aware of the bid and respond properly. Open tenders solicited by the public administration in Italy need to be published at least 50 days before the submission deadline. European project proposals have even longer deadlines.
• Sufficient time to evaluate the proposals received. According to the procedures in place, this could include the time to select and appoint a commission. Once the commission is in place, it needs time to read and evaluate the proposals and write a report explaining the choices. In some cases, commissions might ask for clarifications from the bidders. In this case, additional time has to be allocated so that the bidders can respond properly.
• Time to award the contract.
• Time for the contractor to actually deliver the products or services agreed upon.

For open tenders, this schedule results in months between the preparation of the bidding and the actual start of the work.

Procurement is best scheduled backward, starting from the date on which a specific good or service has to be obtained and moving backward as the time required by each activity is determined.

As a simple example, consider an activity to buy hardware. A possible schedule is shown in Table 6.2. Many other examples are available. See Mills and Reeve (2011) for another timescale.

6.5 An Example

Consider the Theater 3001 project we presented in Section 3.11.

To decide on a payment schedule, a simple approach is that of allocating costs proportionally to the effort required to achieve each project milestone.

Approximating the numbers a bit, we get

• M1 Specifications: €8500
• M2 Environment and system: €31,000
• M3 Experimentation: €1500.

To minimize the risks related to financial exposure, we have different possibilities:

1. We can choose a “time & materials” (or “retainer”) contractual agreement, with payments fixed on a monthly basis. The schema ensures that we get paid for the work performed and, in the case of the retainer contract, for the work we will perform. However, these options might not be suitable for the client.
2. We can choose a “fixed cost” contractual agreement, requiring an advance payment to get started and other regular payments, based on the achievement of project milestones. This schema minimizes risks on both sides, as explained below.

A possible allocation of payments is shown in Table 6.3. We evaluate the schema considering financial exposure and fairness of the agreement between the client and the supplier.

Concerning the first point, we have a schema in which the client makes an initial investment that covers the expenses at the start of the project. The supplier then needs to cover the project costs with internal resources. The final payment is then used to balance any due. (Note, however, that the tariffs we use already include a profit; thus, the actual exposure of the supplier is lower than what the numbers show.)

It can also be observed that

• The payment associated with M1, together with the advance payment, is about the value of the work to produce the deliverables associated with the milestone. It is thus fair both to the client and the supplier.
• The payment associated with M2 is necessarily lower than the value of the deliverable, since we need to take from somewhere the funds to cover the initial payment.
• The payment associated with M3 (end of project) is higher than the value of the work to achieve the milestone. This is to keep the commitment of the supplier in the project. Consider, for instance, the situation in which the payment associated with the last milestone is equal to or lower than the costs sustained by the supplier. Reasoning from a purely economical point of view, it would be indifferent or, worse, counterproductive for the supplier to continue work in the project.

For the reason highlighted above, the final payment usually has a higher incidence than the one shown in the table.

6.6 Questions and Topics for Discussion

1. What are the main strategies to determine software price?
2. Consider the Theater 3001 project. Find the break-even point if we are given the opportunity to license the system at €3000 each. What would be the price we need to set if we intend to break even with 500 licenses?
3. What are the operational costs of the Theater 3001 system? Provide your estimation of the costs.
4. What are the aspects to consider when leasing a software?
5. Set a leasing price for the Theater 3001 system.
6. Are there components of the Theater 3001 project you could make open source without compromising opportunities for a business? What kind of additional benefits could you achieve with such an arrangement?

References

Black Duck Software, 2013. Ohloh home page. Available at http://www.ohloh.net. Last retrieved May 25, 2013.

Bruxam, P., H. Diefenbach, and T. Hess, 2013. The Software Industry—Economic Principles, Strategies, Perspectives. Springer-Verlag, Berlin, Heidelberg, Germany.

Burke, R., 2006. Project Management, Planning and Control Techniques (4th ed.). John Wiley & Sons, New York, NY, USA.

Davidson, N., 2012. Don’t Just Roll the Dice. Efendi Minibooks, United Kingdom.

Feil, P., K.-H. Yook, and I.-W. Kim, 2004, Spring. Japanese target costing: A historical perspective. International Journal of Strategic Cost Management, 11, 10–19.

Free Software Foundation, 2007, June. GNU general public license. Available at http://www.gnu.org/licenses/gpl.html. Version 3, 29 June 2007. Last retrieved May 25, 2013.

GNU Software Foundation, 2013, March. Overview of the GNU system. Available at http://www.gnu.org/gnu/gnu-history.html. Last retrieved May 25, 2013.

Hunt, B., 2010. Tips on the structure and timing of payments for web site projects. Available at http://www.webdesignfromscratch.com/business/payment-timing-structure-tips/. Last retrieved July 8, 2013.

Kornblum, J., 1998, March. Netscape sets source code free. Available at http://news.cnet.com/2100-1001-209666.html. Last retrieved June 28, 2013.

Lewis, P. H., 1995, March. Netscape knows fame and aspires to fortune. Available at http://www.nytimes.com/1995/03/01/business/business-technology-netscape-knows-fame-and-aspires-to-fortune.html?pagewanted=all&src=pm. Last retrieved November 15, 2013.

Maylor, H., 2010. Project Management (4th ed.). Pearson, Harlow, England.

Mills & Reeve, 2011. Timescale tracker. Available at http://www.mrprocurement.co.uk/files/Uploads/Documents/timescale_tracker.pdf. Version 1.07. Last retrieved November 15, 2013.

MIT, 2013. The MIT license. A template is available at http://opensource.org/licenses/MIT. Last retrieved May 25, 2013.

Open Source Initiative, 2013. Open source initiative, license by name. Available at http://opensource.org/licenses/alphabetical. Last retrieved May 25, 2013.

Open Source Resource Center, 2012. Open source license data. Available at http://osrc.blackducksoftware.com/data/licenses/. Last retrieved May 25, 2013.

The Secretariat of the African, Caribbean and Pacific (ACP) Group of States, 2012. ACP-EU Cooperation Programme in Science and Technology II—Guidelines for Applicants. Available at http://www.acp-st.eu/content/acp-eu-cooperation-programme-science-and-technology-ii-st-ii-call-proposals-launched. Last retrieved November 15, 2013.

Sommerville, I., 2007. Software Engineering (8th ed.). Addison-Wesley, Redwood City, CA.

Stack Overflow, 2008. What payment structure do you use for small projects? Available at http://stackoverflow.com/questions/383975/what-payment-structure-do-you-use-for-small-projects. Last retrieved July 6, 2013.

US Government, 1998. 48 cfr 16.306—cost-plus-fixed-fee contracts—code of federal regulations. Available at http://www.gpo.gov/fdsys/granule/CFR-2010-title48-vol1/CFR-2010-title48%-vol1-sec16-306/content-detail.html. Last retrieved April 25, 2013.

Wysocki, R. K., 2011, October. Effective Project Management: Traditional, Agile, Extreme (6, illustrated ed.). John Wiley & Sons, New York, NY, USA.