There are traditionally two styles of contracts, fixed-price and time & materials. E7 Systems can work with either style of contract, based on customer needs.

Larger companies prefer and often require fixed-price contracts. This enables them to budget a specific amount of money for a promised solution.

Startups are frequently willing to work with time and materials contracts because they frequently change their requirements as products are being developed.

Strictly interpreted, each of these contracts is flawed. With fixed-price the developer holds 100% of the risk. With time and materials the customer holds 100% of the risk. Both of these situations pit the interests of one party against the other.

A further problem occurs when fixed-price contracts are put out to bid. Ask five different software developers to bid on the same project, and you will get wildly different estimates. The highest estimates will be delivered by developers who have padded their bid to reduce their own risk. Likely the low estimates will be delivered by developers who do not understand the full complexity of the problem.

Imagine that a software company operates on a 20% margin. For every fixed-price project that goes 40% over budget the company must perfectly complete two more just to break even. Software companies accommodate for this risk by building insurance into the price of their bid. This actually penalizes disciplined, organized customers who contribute to the completion of their projects.

Software estimation is a notoriously difficult problem in which roadblocks, discoveries, and scope creep all decrease the revenue per hour to the developer. When a software vendor does a poor job of estimation and ends up working for free, the result is lots of shortcuts and a huge mess for the next developer to clean up. While the customer may have saved money in the short term, they would be better off having a strong and committed software development partner.

E7 Systems employs agile methods in bidding and completing software projects.

In the very best case, we can deliver an estimate on the larger projects, with fixed-price bids on individual releases and specific goals and milestones.

For estimating projects we follow a proven method:

• Review our 15 year history of delivering similar projects
• Compare the time and complexity of those projects with the new project
• Ask three smart developers for a top-level educated guess
• Break the project down into its major components
• If necessary, break it down again
• Complete a planning poker session estimating each task
• Include quality assurance, documentation, training and launch
• Compare the detailed estimates to the earlier guesses. If they do not match ask why.

If a project has specific, high risk elements, such as technical challenges that have never been solved before, we will propose up-front programming spikes where we attack only the riskiest coding in the project. The goal is to uncover any weaknesses in the proposed development tools or in the accuracy or effectiveness of required hardware. These spikes give our customers an accurate and realistic view of the project ahead for the least amount of money. These spikes also can provide a startup client with proof of concept that they can use in fundraising efforts.

Occasionally we will encounter a project for which a fixed-price bid cannot be made. Reasons for this include inheriting the code of the previous developer, relying on external systems and devices outside of our control, or incomplete/dynamic definitions of system requirements.

A contract structure that balances risk and serves both parties is ”not to exceed, unless”. In this type of contract, the vendor thoughtfully reviews estimates and provides the client with a work order for the estimated work. No insurance buffer or margin is required. The client sees the developer’s very best, most accurate vision of the project ahead. The client understands that the developer will do everything within their power to complete the work within the time and budget described.

If roadblocks or discovered requirements make it impossible to complete within the defined budget, the developer notifies the client as soon as possible and finds a solution that works for everyone.

Benefits of this contract style include:

• Requirement changes are quickly accommodated
• Unused hours are never billed if the project is completed early
• Developers have the security and motivation to do things right
• Fast-moving customers do not subsidize the slow
• Customers can budget for their projects
• All parties remain motivated to complete the project under budget

E7 Systems has delivered over 500 projects for our customers. Most of these projects were developed with the “not to exceed, unless” contract structure. The majority are delivered under budget. When roadblocks or discoveries trigger the “unless” clause, we frequently find that there is usually a better and easier path to completion than the original project plan.

It is essential to provide regular progress reports and demonstrations so neither party is surprised, and both understand why the original goals or budget are modified.

Traditionally, there are two styles of contract, fixed-price and time and materials. E7 Systems, depending on customer preference, has worked with both styles of contract.

Larger companies prefer and often require fixed-price contracts. This enables them to budget a specific amount of money for a promised solution.

Startups are frequently willing to work with time and materials contracts because they frequently change their requirements as products are being developed.

Strictly interpreted, each of these contracts is flawed. With fixed-price the developer holds 100% of the risk. With time and materials the customer holds 100% of the risk. Both of these situations pit the interests of one party against the other.

A further problem occurs when fixed-price contracts are put out to bid. Ask five different software developers to bid on the same project, and you will get wildly different estimates. The highest estimates will be delivered by developers who have padded their bid to reduce their own risk. Likely the low estimates will be delivered by developers who do not understand the full complexity of the problem.

Imagine to that a software company operates on a 20% margin. For every fixed price project that goes 40% over budget the company must perfectly complete two more just to break even. Software companies accommodate for this risk by building insurance into the price of their bid. This actually penalizes disciplined, organized customers who contribute to the completion of their projects.

Software estimation is a notorious difficult problem, roadblocks, discoveries, and scope creep all decrease the revenue per hour to the developer. When a software vendor does a poor job of estimation and ends up working for free, the result is lots of shortcuts and a huge mess for the next developer to clean up. While the customer may have saved money in the short term, they would be better off having a strong and committed software development partner.

E7 Systems employs, as much as possible, agile methods in bidding and completing software projects.

In the very best case, we can deliver an estimate on the larger projects, with fixed-price bids on individual releases and specific goals and milestones.

For estimating projects we follow a proven method.

• Review our 15 year history of delivering similar projects
• Compare the time and complexity of those projects with the new project
• Ask three smart developers for a top-level educated guess
• Break the project down into its major components
• If necessary, break it down again
• Complete a planning poker session estimating each task
• Include quality assurance, documentation, training and launch
• Compare the detailed estimates to the earlier guesses. If they do not match ask why

If a project has specific, high risk elements, such as technical challenges that have never been solved before, we will propose up front programming spikes where we attacked only the riskiest coding in the project. The goal is to uncover any weaknesses in the proposed development tools or in the accuracy or effectiveness of required hardware. These spikes give our customers an accurate and realistic view of the project had for the least amount of money. These spikes also can provide a startup client with proof of concept that they can use in fundraising efforts.

Occasionally we will encounter a project for which a fixed-price bid cannot be made. Reasons for this include inheriting the code of the previous developer, relying on external systems and devices outside of our control, incomplete or dynamic definitions of system requirements.

We frequently find that the very best contract structure is ”Not to exceed, Unless”. In this type of contract we thoughtfully review our estimates using the methods above and provide the client with a work order for the estimated work. We add no insurance buffer to our estimate. The client sees our very best, most accurate vision of the project ahead. The client understands that we will do everything within our power to complete the work within the time and budget described. If roadblocks or discovered requirements make it impossible to complete within the defined budget, we notify the client as soon as possible and find a solution that works for everyone.

The benefits of this style of contract are as follows:

• Requirement changes are quickly accommodated
• If the project is completed early, unused hours are never billed.
• Developers have the security and motivation to do things right
• Fast-moving customers do not subsidize the slow
• Customers can budget for their projects
• All parties remain motivated to complete the project under budget

E7 Systems has delivered over 500 projects for our customers. Most of those projects were developed with the “not to exceed, unless” contract structure. Most are delivered under budget. When roadblocks or discoveries trigger the “Unless” clause, we frequently find that there is usually a better and easier path to completion than the original project plan.

As an absolute last resort, we face the decision of renegotiation or absorbing the difference. If we have been providing regular progress reports and demonstrations, then no one is surprised and the customer understands the reasons why the original goals or budget need modification.