WASHINGTON DC AGILE (DRUPAL & PYTHON) DEVELOPER
When it comes to estimating web development projects, there is no real science. In the end, it is a guessing game and a gamble to see if the developer can deliver everything required, on time, and within budget. If the developer loses the bet then she loses money, foregoes the profit necessary to invest and grow the business, and possibly suffers a cash flow crunch which jeopardizes her ability to pay her expenses – including payroll, Internet connection, rent, hosting fees, etc. If the developer loses the bet, then the client often loses the bet as well because if the developer doesn’t have the capacity to continue working because she has run out of money, then the client and the project is left stranded – dead in the water.
On the other hand, if the developer wins the bet, then there is often some extra money left over to focus on bugs that are inherent in any software development project, improving the user experience, investing in new people and technology, or pre-funding the warranty against future defects. So, if the developer wins the bet, then so does the client.
But here is the rub … clients don’t want to write blank checks and simply don’t always have unlimited funding. So, clients want some reassurance that if they pay a certain amount of money, they can expect a certain set of functionality, of a certain level of quality and user experience, delivered on or around a specific set of dates or milestones. That is certainly reasonable.
The problem is that no two software development projects are ever the same. No two websites are ever the same. No web developer has ever created the exact same website twice. So, having never done exactly the same thing before, how in the world can you estimate with any level of precision exactly how long it will take or how much it will cost? How can you predict or forecast the obstacles that will fall in your way? How can you predict if the client will answer your questions so you can develop with efficiency?
There are two basic approaches to web and software development plus a hybrid.
- Firm fixed price (FFP)
- Time and materials (T&M)
- Agile development
With firm fixed price (FFP), it is absolutely necessary that the client provide as much detail as possible for the developer to understand exactly what needs to be delivered, what is the acceptance test or criteria to demonstrate performance of those things to be delivered, what environment, conditions, and constraints exist, and how much time is available. That is a pretty tough challenge, particularly when clients often don’t even know what they really want. Most clients think they know what they want, but they don’t know what they don’t know.
And, because clients are client – and not developers – then clients tend to think in higher level terms and their language reflect their business and perhaps user requirements. Client visualize web projects from the first impression (which is very high level) and then drill down into the details. Developers, on the other hand, think in totally different terms, language, and level of detail. While a client thinks about reports, developers think about data elements. While clients think about user navigation, developers think about taxonomy. Clients and developers speak completely different languages. So, it’s no wonder that problems and misunderstandings occur during the web development process.
Indeed, managing expectations is one of the most difficult tasks when it comes to this particular business. Clients need to manage developer’s expectations and developers need to manage client’s expectations.
We have found that there are certain trade-offs that must exist in a software development project.
Variables include scope (functionality), dates (deadlines), cost (budget), and quality (user experience). The fact is, you cannot have it all. Usually, a constraint exists. There is only so much money in any organization’s budget. So, at some point in time, cost will be a factor. Likewise, we don’t live forever and we can’t wait forever, so at some point, dates and deadlines are going to be a factor. And, if we give a certain amount of money for a project, we have certain expectations about what we are going to get and we know that there are certain “must have” items that are required or else the software will be somewhat worthless. So, scope and functionality will ultimately be a factor.
The question is; what is more important – getting the functionality you want or getting it done by a specific date? You can draw a line in the sand for one or two of these factors, but not all. You have to choose and you have to prioritize what is the most firm or fixed and what is the most fluid or flexible. This becomes especially important mid-way through the project when, suddenly, everybody realizes that we discovered something new that we had not known or discussed earlier. The issue simply never came up or people simply has assumptions that were never flushed out.
When these epiphanies occur during a project, we have to look at this chart and decide; are you willing to slip the schedule to include this new feature or acceptance standard, are you willing to increase your budget to get it into this release, are you willing to put aside some other functionality so we can include this new functionality? Trade-offs will occur and it is mission critical that everybody be aware of this at the beginning of a project and throughout.
For this reason, we really prefer the Agile Development Methodology where the sprints are shorter (one week to one month), and we can break down the requirements into greater detail and focus on a smaller bunch of tasks and functionality at a time rather than trying to wrap our head around a massive, inconceivable project or system. Just like eating an elephant, you can’t consume it one day or even a week. It takes a while and you have to carve it out piece by piece.
Agile development allows us to keep in mind the big picture and road map while focusing on scope and functionality that can be more easily understandable, predictable, and accomplished in a reasonably short period of time. Scrum planning and 1-4 week sprints allows us to deliver quality software faster so we can make continual, iterative improvements to a system rather than lurching forward or leapfroging over longer periods of time.
If you would like to learn more about the pros and cons of firm fixed price versus time & materials versus agile development; please give us a call.
