“How much does X cost?” is one of the most common (and yet complicated) questions in the software engineering industry.
Estimating development projects is rarely a straightforward process, because of the broad gap between “simple” and “truly complex” variation of the same business problem, along with the external context (all 3rd parties) — and let’s not forget unclear requirements and scope creep.
Estimates Are Extremely Hard
There’s a good reason why many service providers:
- build a limited set of solutions in order to stick to sane ballparks,
- venture into building products, or
- productize their services under a manageable scope.
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.
In fact, it’s been 5 years now and I couldn’t be happier for moving away from a waterfall model with ambiguous estimates across the board.
The thing is, designing a website or building a mobile app is not a straight-forward process.
What Clients See in Estimating a Project
Most clients imagine the following process:
- An initial discussion or a review of the existing brief
- A formal (or informal) agreement of the scope and deliverables
- Setting up a deadline and a launch date
- The developer/designer does whatever they’re supposed to do
- The project is 100% complete
With that scenario, evaluating the scope should be trivial, right?
70% of Estimated Projects Don’t Deliver
Which is why CHAOS Group reports over 70% of failing projects globally when asking for an estimate upfront and building them like a waterfall project:
Note the massive drop in 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.
A Realistic Web Project Estimation Workflow
In reality, what happens most of the time with small businesses and freelancers (or small dev teams) is the following:
- The vendor agrees on the predefined set of features/UI/specification.
- They spend the allocated development time.
- The client asks for a couple of small updates.
- Then another dozen of small and medium-sized updates.
- Suddenly, it turns out that certain areas aren’t “as I imagined them to be”.
- Refactoring or rebuilding.
- The client comes up with a set of random features that they wanted to have in the beginning.
- A lengthy — and often heated — discussion around the initial scope and all the gaps in the original proposal.
- Another set of bugs due to last-minute changes.
- Communication gaps, missing assets, incorrect information provided by the customer, etc.
- Additional work past the original deadline.
- Emails, chat messages, calls, more emails, additional scope, pitching new features around the last-minute bugs due to out-of-scope requirements.
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.
Project Documentation May Impact The Estimate
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.
4 Ways to Make Estimates Profitable
There are only four cases where software development is profitable for the service provider almost all the time:
- Selling long and detailed discovery sessions upfront – which ends up being a minimum viable product that already includes the core features, the main design concept, and lengthy detailed documentation paid by the client before the “actual development”.
- Carefully crafting contracts that legally bind a client to the vendor’s interpretation of scope – and charging upfront most of the time. That may get ugly in court as clients often disagree given the mismatch between the build and the initial “idea”.
- Massively surcharging with a large multiplier of the original job in order to cover all losses from scope creep and communication overhead.
- Offering agile development in the first place.
Except for the last option – iterative agile development where costs and scope can be adjusted on the fly – everything else requires some overhead or an 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).
Working With Multiple Decision Makers
Again, make no mistake – 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, the worst-case scenario maybe 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:
Complex Algorithms for Estimating Web Projects
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.
Case Study 1: Estimating a Web Design Through a Wireframe
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:
- Responsive design hasn’t been included in-depth. You’ve introduced specific breakpoints for some resolutions but the customer asks for a fluid layout.
- The grid has been limited to 1980px wide (or so). The client asks for a full retina support – or generally any screen out there. This results in humongous images killing the load time of the site.
- Scaling large images for sliders and hero sections may be rough. Keeping the height fixed will crop the image in unknown ways. Scaling diagonally (retaining the aspect ratio) will result in an extremely high slider section, requiring several scrolls until you see any text.
- Text positioned within the slider will get distorted or overlapped at times. The font color may fall into a same-color image zone leading to reduced readability.
- Long text may fall under the banner itself, breaking the design consistency. Or expanding the image in unknown ways.
Additional Web Design and Development Challenges
Have you noticed that we’ve only touched on grid width and header image so far?
- Fonts may come from a 3rd party font provider – impacting site load at times or hitting limits in case of traffic peaks.
- Content may come at a later point. While
designhas been planned based on the initial mockups, differences in title length/image size will break almost all grids within the page – such as archive post columns, project features aligned next to each other, or anything that is horizontally aligned.
- A site admin may upload a tiny image (a thumb or an icon) for a section. How is that supposed to fit in – scaling and distorting the image, keeping it small (with tons of whitespace surrounding it)?
- You may update the landscape image zone with a portrait photo. This often leads to trimming one’s head or the top text.
- Certain sliders, galleries, dynamic accordions may misbehave on iOS or Internet Explorer/Edge. Debugging becomes a nightmare.
This is merely an excerpt of everything that happens during the development process. Let’s take a look at another example.
Case Study 2: Estimating a Deployment Process When Going Live
Okay – the project development has gone smoothly. The website has been approved on your staging platform.
- Design – checked.
- Front-end work – checked.
- Back-end work – checked.
Permission for hosting the project – granted.
I’ll list several use cases that I’ve had to deal with personally over the past years.
Several Use Cases
- IIS hosting. WordPress (and PHP) are commonly hosted on a Linux stack with Apache/nginx, mod_php or php-fpm, MySQL. IIS may not fully support everything that we design and develop out-of-the-box. Database connections may time out. Complex rewrite rules will need to be rebuilt.
- A limited and restricted hosting plan. Any random and cheap host that runs an extremely outdated version of PHP or MySQL, not supporting features that are designed for newer versions. Deprecated plugins manually blacklisted by the vendor. Specific firewall rules you need to coordinate with support (multiple times). We’ve even had a client asking for a Yahoo! hosting which ran on PHP4, making this absolutely impossible (leading to us purchasing a normal hosting for 5 years and giving it away).
- Domain hassles. Hosting a site on a new server and pointing the records to the new host. Clients often forget where their domain is hosted – leading to days or even weeks of looking around. A previous vendor may have the “keys” to the domain registrar. After some back and forth, this gets resolved – until you face another obstacle with a Cloudflare account or another web proxy controlled in-between. Certain files and folders may be hosted with the old account, requiring manual transfer or even integration into the new platform.
- A barebone VPS server with limited access. An enterprise client of ours provided us with their VPS server we were about to use. At first, it required 2-factor authentication with a local telecom. They didn’t provide us with the root (or sudo) user, preventing us from installing a LEMP stack. After some back-and-forth, it turns out the server had blacklisted apt-get – leaving us copying packages over through scp and rsync. Oh, by the way, the initial VPS was running a custom, outdated Linux distro lacking almost all packages. The list goes on, but this process took nearly 80 hours of hard work for something that takes under an hour with a standard host.
Case Study 3: Implementing a 3rd Party Platform (CRM, ERP)
One of our corporate clients requested a new 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 the API documentation using SOAP in a PDF format.
Building our own SOAP plugin took a couple of 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.
400 Error Codes – a Default Response
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.
Here’s what happened when we moved to development retainers instead.