In today’s world, software development can be somewhat of a minefield. Unlike building a physical object like a house or a piece of furniture, software development lends itself well to an iterative approach not possible for other engineering endeavors. Software development — defined in this article as developing software to solve a business problem — has unique qualities in project management styles that can present contract challenges for the customer and the developer.
There are many pricing and project management models available; time and materials and fixed-pricing models along with agile and waterfall project management models are used widely in the software development for hire industry. In this article I’ll discuss the advantages of one over the other, and maybe even dispel a few myths.
In the late 1990s, I built software solutions using what is commonly referred to as the “waterfall” method of development. A widely-accepted method, the waterfall model is a sequential design process, often in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design, Construction, Testing, Production/Implementation, and Maintenance.
A developer starts a phase and moves from one to the other until the project is completed. Because software engineering is the art of applying a technology solution to a business need, it is a collaborative effort between the business expert and the software engineer. In my experiences, I would gather requirements from the business expert (the client) then work up a fixed-price contract to build the software. After the requirements-gathering phase, the client would disappear and I would design, develop, and deploy the solution. At the end of the deployment, I would then sit down and demonstrate that each and every requirement had been met.
Happy ending, right? Wrong!
After several of these types of fixed-price arrangements, I began to dread the requirements validation meeting that signaled the project’s end. While I could always demonstrate that every requirement had been met, the client seldom left happy. The problem was that while all the high-level features had been addressed, the more nuanced elements were typically left to a software engineer’s interpretation. For instance, the client had red in mind, but the engineer used blue. Or the client expected a service that was set to run daily, should be configurable, but the engineer hard-coded it.
With the waterfall model, the client’s requirements may be fulfilled, but they may be unhappy that the sometimes, hundreds of decisions made during the course of a project, have been decided without their input. But unless the client is willing to accept a higher cost (which may exceed return on investment) for extensive collaboration requirements and a design phase to map out every detail in advance, it is likely the end result will not change.
Many people fall into the trap of assuming that because a certain software feature appears simple, it should be easy to develop. As my UWF computer science professor would say, people often see software as some sort of magic and all that is needed to make it work is a little “magic smoke.” But software engineering is not unlike other forms of engineering. Hell, engineering is part of the name!
Before founding Bit-Wizards, I spent a few years working in the “agile” development model. In this model, development is based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. The agile method allows for changes throughout the process and the client is involved in all the nuanced decisions made along the way. This is a very effective development methodology, made possible by the inanimate (magical) quality of software, which allows for changes with labor and time as the only costs. Show a design, the client asks for changes, and the developer makes the changes. This model doesn’t work so well for projects involving physical objects. For instance, a house; build it, show it, tear it down, build it again.
The agile method allows for results that include a higher measure of desired functionality. And the agile approach is a great collaborative way for business and technology teams to develop software solutions. However, using fixed-price contracts with the agile method can often make relationships between client and developer contentious and difficult.
Businesses cannot wait until the end of a project to determine time and costs; estimates are needed at the front end for decision making. This presents a challenge for the developer. If the bid is too low, he’s on the hook for overruns. So, the technology vendor is motivated to do as little as possible to meet the requirements, collect their payment, and move on. While the business client is motivated to “gold-plate” everything and ask for the most elaborate features be worked into the fixed price.
The Time and Materials Difference
Using the agile development approach under a time and materials contract, rather than fixed, often solves the contention challenges as it incentivizes quicker turnaround times and other behaviors key to successful projects. In an agile, time and materials environment, the technology team is incentivized to give the client anything they feel has value, and perhaps even propose additional features understanding that they will be paid for their time — if the business team believes those new features will add value to the project. Conversely, there is a cost for each new feature the client adds, which removes the incentive to “gold-plate” the application unless those features add value. Everyone is now motivated for success.
While many businesses initially may have concerns about time and materials contracts, most can be mitigated with realistic estimates, close monitoring, and a proven track record of success. In my experience, the main objection to a time and materials project is that clients feel like they are just writing a blank check to a development company. This myth is hard to understand because it has no foundation in reality. Just like any other approach, an estimate is provided and clients make decisions based on what’s in their best interest. So, during the course of a project the client has a dollar amount of what they expect to pay at the end and any changes along the way will affect the final price based on what is or isn’t approved.
Not all software companies are created equal and using agile development with time and materials doesn’t eliminate the possibility of failure. A client must have regular contact and reports on progress from the software vendor. For instance, Bit-Wizards reports all time spent twice a month detailing who did the work, what was done, what day it was done, and of course how much time was spent.
And at the end of the day, any reasonable decision maker would be remiss to neglect appropriate due-diligence of a development company they intend to hire — further mitigating risk of project failure or unexpected cost overruns.
At Bit-Wizards, we work almost exclusively with time and materials agreements using an agile development approach. And while we occasionally work outside that model, we have found that the time and materials approach often provides the advantage of creating a collaborative endeavor, rather than an adversarial one.
Please feel free to comment below or email me at firstname.lastname@example.org, I would love to share thoughts and ideas with you!