Billing Matters

Some clients prefer vendors to offer fixed prices for their projects. The perceived benefit of a fixed price is that it appears to remove uncertainty from the cost, timeline and scope of the project. The contract controls three of the four variables outlined in Kent Beck’s Extreme Programming Explained. Clients are happy to have control over these aspects of the project, unaware that in so doing they may be relinquishing control over the fourth variable: quality.

What does it take to produce a high-quality product? First, we find that the best products are the result of the collaborative efforts of clients and vendors – business and development – because you need the expertise of both parties. Second, a project needs to be able to adapt to the inevitable changes that it will encounter along the way. All features don’t have to be fully defined at the beginning of the project. Both clients and vendors are in a better position to work out the details of a feature or set of features as time moves on.

A fixed-bid contract works against these principles of quality. It does not easily adapt to changes because the contract determines the scope of the project and straying from that contract involves time-consuming renegotiation, which detracts from the working relationship of clients and vendors. Second, the contract does not align the incentives of clients and vendors. The focus is not on producing high-quality software, but on fulfilling the said contractual agreements. The development question is no longer “what will be best” but “what does the contract stipulate.”

The picture described here is one of competing interests on opposite sides of an inflexible document (i.e. wall) between clients and vendors that prevents effective communication. In the long run, software produced on this model is more costly, and we’re not just talking about cost of maintenance. Even adequately functioning products that fit the contractual requirements can have additional opportunity costs: a software product may miss its intended market, or an internal system may fail to address inevitable inefficiencies.

How AO Works

At Atomic Object, we run fixed-budget, scope controlled projects. We bill based on hours spent rather than feature completion, at regular intervals throughout the lifecycle of the project. “Fixed-budget” means that we reliably hit fixed budgets and work with our customers collaboratively to build the best possible software for that budget. “Variable scope” entails that the product that’s delivered isn’t outlined in a contract but controlled by the client. We help ensure that we build the right features, and build them to the right level of complexity, to get the most possible value for the fixed budget. The client always knows where the budget is and what features in the backlog remain. The following techniques work together to ensure full transparency between the client and the developers.

• Prioritizing Features
• Tracking Velocity
• Working in Weekly Iterations

Prioritizing Features. While in the planning phase, we help our clients produce a list of all the features they desire of their product, ranking them in order of importance. The developers then use this list to structure development. (Clients can change the priority of any feature during iteration meetings.) Once established, this list can be used to estimate how long the project will take. Rather than assign an arbitrary amount of time to the feature, we measure the tasks according to their relative complexity. If adding a feature has a complexity level of one point, another that is twice as hard will be allotted two points in the schedule.

Velocity Tracking. Once each feature is estimated using a relative scale, we can make an iteration budget (e.g. ten points this iteration), and then measure our progress. If ten points takes us one week, we now can estimate that a one-hundred point project will take ten weeks. By tracking our velocity, we are able to produce an increasingly accurate estimate of the project’s completion time. Clients are part of this process—they know exactly what our velocity is, how it compares historically, and how it affects the future of their project.

Working in Weekly Iterations. We release tested, functional software to clients in weekly iterations, offering them a good sense of where the team is and assuring them that the released features match their expectations. The weekly iterations provide clients with a platform to change their minds without needing to renegotiate a contract. Rather than dropping off a contract and returning three months later for the finished product, clients can see the progress as it happens, mitigating the risk that the product isn’t what they had in mind. Moreover, these weekly checkpoints assure clients that their developers are using their time as efficiently as possible. Because clients collaborate with the developers on a weekly basis, the progress is completely transparent. Tracking our velocity and breaking up projects into smaller tasks incentivizes developers to work more thoroughly and efficiently.

The advantage of doing fixed-budget, variable scope projects over fixed-bids is that it removes the wall that a contract creates, promoting communication and collaboration between clients and developers. Everyone shares the responsibility for the project’s success when communication is open—and that means higher quality software.