Strategic Estimation Frameworks for Web Development and Digital Product Delivery

“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 variability in solution complexity and scope variation of the same business problem, along with the external context (all 3rd parties) – and let’s not forget ambiguous or evolving business requirements and scope expansion and requirement drift.

The Complexity of Estimation in Custom Software Delivery

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.

Client Perception vs. Actual Delivery Complexity

Most clients typically assume a linear delivery model the following process:

1. An initial discovery and requirement alignment or a review of the existing brief
2. A formal (or informal) formal scope definition and contractual alignment and deliverables
3. Setting up a deadline and a launch date
4. The execution phase based on predefined deliverables they’re supposed to do
5. The project is full delivery against initial scope definition
6. Launch

With that scenario, evaluating the scope should be trivial, right?

Failure Rates in Fixed-Scope Project Estimation Models

Which is why CHAOS Group reports over 70% of project delivery failure rates globally when asking for an fixed-scope upfront estimation and building them like a waterfall project:

Note the massive drop in failed projects when applying a good agile methodology instead.

Estimation complexity in custom development environments.

In my experience, the amount of iteration cycles and stakeholder communication loops, scope creep, and operational and coordination overhead may result in 5-10 times the actual development time required for the initial brief.

Low-maturity service providers cause regressions, deliver suboptimal delivery 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.

Real-World Project Delivery Dynamics and Scope Evolution

In reality, what happens most of the time with small businesses and freelancers (or small dev teams) with website development cost 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 incremental change requests.
• Then another dozen of incremental change requests.
• 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 unplanned feature additions that they wanted to have in the beginning.
• A lengthy – and often stakeholder misalignment and scope disputes around the initial scope and all the gaps in the original proposal.
• Another set of defects introduced during late-stage changes due to last-minute changes.
• Information asymmetry between stakeholders, missing assets, incorrect information provided by the customer, etc.
• Unplanned delivery scope expansion 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 a 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.

Impact of Documentation Complexity on Estimation Accuracy

We’ve even worked on projects that included extensive technical documentation. Some of them ended up with months of additional cross-functional stakeholder alignment cycles 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 multiple valid implementation approaches by five independent service providers.

Therefore, estimation complexity in custom development environments.

As a result, the actual scope is indeterminable.

Commercial Models for Managing Estimation Risk and Profitability

There are only four cases where software development is profitable for the service provider almost all the time:

1. Selling long and detailed paid discovery and solution definition phases 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”.
2. Carefully crafting legally structured scope governance models 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”.
3. Risk-adjusted pricing strategies with a large multiplier of the original job in order to cover all losses from scope creep and communication overhead.
4. Offering iterative and adaptive delivery frameworks 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).

Stakeholder Complexity and Decision-Making Alignment Risks

Again, make no mistake – development cost estimates are extremely hard.

There are additional challenges getting in the way. Some business owners have multi-stakeholder decision environments who are lack of stakeholder alignment. Operational delays and resource dependencies often push back a project despite the initial deadline. Certain criteria such as security compliance or performance KPIs may be in strategic and execution misalignment. Iterative design cycles 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 the 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 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:

https://www.youtube.com/watch?v=Am9tlsmcnPI

Estimation Models and Predictive Cost Frameworks

With that in mind, service providers rely on their former experience and their established resource cost structures combined with the contingency buffers and operational overhead for communication, QA, packaging, delivery, and 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 stakeholder management and negotiation capabilities, how detailed your specification is, your contract and the mutual understanding of the project.

Case Study: Design Estimation Risks in UI/UX and Front-End Delivery

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). UI/UX wireframes and design artifacts may also be discussed upfront.

Okay, you end up with a sitemap and some sketches. The deadline is clear, the design has been decided upon, and the website would be hosted by a known hosting vendor.

Without any additional clarifications, here’s what may happen in between:

1. Responsive and adaptive design frameworks hasn’t been included in-depth. You’ve introduced specific breakpoints for some resolutions but the customer asks for a fluid layout.
2. The layout constraints and resolution frameworks (or so). The client asks for full retina support – or generally any screen out there. This results in humongous images killing the load time of the site.
3. 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.
4. 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.
5. Long text may fall under the banner itself, design inconsistency and layout degradation consistency. Or expanding the image in unknown ways.

Operational Risks in Design Implementation and Content Integration

Have you noticed that we’ve only touched on grid width and header image so far?

• Third-party asset dependencies font provider – impacting site load at times or hitting limits in case of traffic peaks.
• Delayed content delivery dependencies point. While the design has 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 low-quality asset inputs (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, and dynamic accordions may misbehave on iOS or Internet Explorer/Edge. Complex cross-platform compatibility issues.

This is merely an excerpt of everything that happens during the development process. Let’s take a look at another example.

Case Study: Deployment Complexity and Infrastructure Constraints

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 legacy technology stack limitations 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 and DNS management dependencies. 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 extended coordination cycles, 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: Third-Party Integration and API Reliability Risks

One of our corporate clients requested a new third-party system integration (CRM/ERP). This is fine – all of them have existing integrations available (through plugins or libraries) or at least decent documentation.

Of course, that was not the case here.

A week after, we’ve been provided the integration documentation and API specifications using SOAP in a PDF format.

Building our own SOAP plugin extended validation and QA cycles. 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 inaccurate or incomplete technical documentation, and some symbols were stripped or missing. An updated copy was provided with the right SOAP request.

Conclusion: Managing Uncertainty in Custom Development Estimation

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 inaccurate or incomplete technical documentation 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 unforeseen edge scenarios.

Fixed-scope pricing models will make that a resource-intensive estimation process. Even if that’s considered continuous scope evolution, requesting additional payment for that overhead may fail in the end.

Here’s what happened when we moved to development retainers instead.