There’s a good reason why many service providers:
I wrote a detailed post on Why Are Estimates Challenging For Custom Development Work? and the reason we’ve switched to a retainer-based model. It causes less friction while generating better results and allows for an adequate internal workflow.
The thing is, designing a website or building a mobile app is not a straight-forward process.
Most clients imagine the following process:
With that scenario, evaluating the scope should be trivial, right?
Which is why CHAOS Group reports over 70% of failing projects globally when asking for an estimate upfront and building them as a waterfall project:
Note the massive drop of failed projects when applying a good agile methodology instead.
Estimates are extremely hard.
In my experience, the amount of back and forth, scope creep, and communication overhead may result in 5–10 times the actual development time required for the initial brief.
Less experienced providers cause regressions, deliver low quality, or can’t estimate their time due to the lack of experience. But proficient vendors face the same challenges in terms of communication, delays, missing assets, infinite back and forth, pushing back deadlines and redefining the initial scope of the project.
In reality, what happens most of the time with small businesses and freelancers (or small dev teams) is the following:
It’s not even the client’s fault. The problem is that the original scope is always fluke, vague, and up for interpretation.
Fixed fee projects are built in a single iteration. As a result, most of the actual requirements are to be determined during the actual implementation phase.
We’ve even worked on projects that included 300+ pages of documentation. Some of them ended up with months of additional discussions through project managers, team leaders, CEOs, and even lawyers interpreting the possible scenarios where a certain requirement is met.
Surprisingly, a seemingly clear and unambiguous assignment usually may be built in 5 completely different ways by five independent service providers.
Therefore, estimates are extremely hard.
As a result, the actual scope is indeterminable.
There are only four cases where software development is profitable for the service provider almost all the time:
Except for the last option – iterative agile development where costs and scope can be adjusted on the fly – everything else requires some overhead or initial commitment by the client.
Most service providers who sell fixed fee projects try to combine a somewhat detailed specification with enough overhead that could handle part of the overhead. It doesn’t work at all times but it’s a common compromise on the market.
There are worse alternatives (such as abandoning the project due to miscalculations and a tough communication process).
As a reminder – estimates are extremely hard.
There are additional challenges getting in the way. Some business owners have multiple decision makers who are not on the same page. Vacations or asset delays often push back a project despite the initial deadline. Certain criteria such as security compliance or performance KPIs may be in misalignment. Design revisions may be endless – even if an initial scope has been provided.
Each fixed quote is based on the initial understanding of the service provider for the scope of work and amount of time required to get the project done.
There are some formulas that try to bridge the gap between the “best case scenario” and “worst case scenario”:
Usually, worst case scenario may be 20–50 times larger than the best case one due to all of the challenges enumerated above. This calibrates the formula to something that’s “somewhat feasible”.
You can find a practical explanation of the formula in Chris Lema‘s training video.
With that in mind, service providers rely on their former experience and their established hourly rate combined with the additional expected time for communication, QA, packaging, delivery, deployment. This is somewhat arbitrary and often doesn’t work as seen in the CHAOS group chart.
The estimate that you will receive (or are about to give) is likely a similar one. Increasing the chance for success is entirely dependent on your communication and negotiation skills, how detailed your specification is, your contract and the mutual understanding of the project.
Almost every website development project includes some theme development or customization.
A common way to approach that is discussing a theme build or extending an existing theme through a child theme (or customizing a powerful and complex premium one). Wireframes or sketches may also be discussed upfront.
Okay, you end up with a sitemap and some sketches. The deadline is clear, design has been decided upon, the website would be hosted by a known hosting vendor.
Without any additional clarifications, here’s what may happen in-between:
Have you noticed that we’ve only touched on grid width and header image so far?
This is merely an excerpt of everything that happens during the development process. Let’s take a look at another example.
Okay – the project development has gone smoothly. The website has been approved on your staging platform.
Permission for hosting the project – granted.
I’ll list several use cases that I’ve had to deal with personally over the past years.
One of our corporate clients requested an integration with their own CRM. Which is fine – all of them have existing integrations available (through plugins or libraries) or at least a decent documentation.
Of course, that was not the case here.
A week after, we’ve been provided an API documentation using SOAP in a PDF format.
Building our own SOAP plugin took a couple days and we started testing. There was something fishy as some of our parameters weren’t passed over. No response, but we pointed that to a third server intercepting the requests.
Turned out that the documentation was incorrect, and some symbols were stripped or missing. An updated copy was provided with the right SOAP request.
Testing for a couple more days led to no response. Scheduling a meeting with IT took a while – until they told us that the server will ALWAYS respond with a 400 error code regardless. It’s a security measure.
We are distributed, so the only way we could test was: submit a request, call IT, hope someone is around, check if the request has been submitted.
This took forever. At some point, some of our requests went through – but not all of them. Another week later, turned out that documentation is incorrect again – some arguments we were assigning (as a part of the request array with nearly 200 parameters) were wrong. We were supposed to use other data vectors named incorrectly.
Long story short, things can and will go south more often than not. As much as you try to sift through the project requirements and pinpoint every single detail, you’ll always end up with edge cases. Fixed-fee estimates will make that a tedious process. Even if that’s considered scope creep, requesting additional payment for that overhead may fail at the end.