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 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, in which progress is often seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design, Construction, Testing, Production/Implementation, and Maintenance.
A software 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) and 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 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 and 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 decisions (sometimes hundreds of them) made during the course of a project have been decided without their input. However, unless the client is willing to accept a higher cost for extensive collaboration requirements and a design phase to map out every detail in advance, the end result will likely 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 computer science professor at University of West Florida would say, people often see software as some sort of magic, and all that you need to make it work is a little “magic smoke.” However, 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, software 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.
The agile method allows for results that include a higher measure of desired functionality. The agile approach is also 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 clients and developers 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 software developer. If the bid is too low, he’s on the hook for overruns. As a result, the technology vendor is motivated to do as little as possible to meet the requirements, collect their payment, and move on. Meanwhile, the business client is motivated to “gold-plate” everything and ask for the most elaborate features to be worked into the fixed price.
Let’s look at the time and materials difference
Using the agile software development approach under a time and materials contract (rather than fixed) often solves the contention challenges. This is because it incentivizes quicker turnaround times and other behaviors that are 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 a software development 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 so 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, twice a month Bit-Wizards reports all time spent; detailing who did the work, what was done, what day it was done.
At the end of the day, any reasonable decision maker would be remiss to neglect appropriate due-diligence of a software 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. Though 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.