6 Things We Look for When Estimating a Website Project
Scope and complexity should directly relate to your business objectives. How do we determine what makes a website more or less complex to design and build?
In a previous article, I addressed the wide range of costs associated with website projects. In this follow-up, I’ll go deeper into the individual factors we look for to determine, specifically, what makes a website more or less complex to design and build.
1. Company governance
The first broad category we look for is the size, makeup, and decision-making process of the company itself. This gives us insight into the number of workshops, stakeholder interviews, deliverable reviews, iterations, and opinions we’ll need to account for. Some specifics we’re looking for:
Number of stakeholders - How many people will be involved in project decision making and approvals? Is there a core set of stakeholders that will be more closely involved day-to-day? Is there one central point of contact that will be responsible for consolidating feedback and enforcing decision deadlines?
Number of site admins/editors - How many people will use the CMS to enter, edit, review, and publish content across teams? Will permissions control between all users be simple or complex?
Clarity and consensus of site needs and goals - Is there a clear and singular goal that the website serves? Is that easy to quantify in KPIs? What kinds of improvements are needed or desired in order to accomplish business objectives?
2. Work already completed
Second, we try to understand what our starting point will be and how much work, if any, has already been completed internally. Examples of work that may already be completed prior to our being engaged:
Any internal discovery - It’s possible that some of what we’d typically do in Discovery has been completed and documented internally, like stakeholder interviews, goal and KPI definition, or site analytics review and findings. This doesn’t eliminate our need to complete discovery, but it does help shorten the time spent on it.
Existing research - If the client has conducted research about their audiences, we’ll have a clearer jumping-off point for our activities. This will increase our confidence in designing solutions and reduce the need for us to complete additional research upfront.
Brand/design guidelines - Do they exist? Are they robust and flexible? Do they provide specific guidance for the web that also supports responsive design and accessibility? If they don’t, we’ll need to spend more time on design exploration and definition.
UX or design for web - Sometimes, clients approach us with more fleshed-out thoughts about the website's new UX or UI. This doesn’t necessarily reduce the time needed to complete these things, as the work needs to meet our standards, be compliant with accessibility requirements, take responsiveness into consideration, and be detailed enough to build from.
3. Tech stack
A key piece of the scope puzzle is the technology that supports the website, from the CMS, to hosting, to security. We try to understand the baseline (what exists) and ambitions for change (what will exist).
Technical infrastructure definition - How much do we know or not know about the existing technical infrastructure? What CMS is the site on? Is there a desire to change any piece of that infrastructure? If so, are we expected to advise on those decisions?
Complexity of security and DevOps requirements - Are there specific security or hosting requirements that need to be vetted and validated with whatever solution we’re proposing? Are any of these requirements above and beyond what we typically see?
4. Site size
Probably the most obvious and surface-level determiner of scope is the sheer size of the site, split into a few size types:
Breadth and depth of content - How many top-level sections and categories of content exist? Per category, how deep does each content trail go? What volume at each level currently exists and needs to be accounted for?
Number of content types - From blog posts to video pages to pricing pages to landing pages, what are the various content types that exist? This will determine the number of unique templates and supporting components, shared or unique, that will need to be designed and built to support the new site.
Number of domains/sites - We often interact with sites that extend to additional subdomains or microsites. Some are powered by the same CMS as the main site and others are completely separate. Are these sites in scope? If so, do we plan to consolidate them or continue to treat them as separate? If separate, how much of a change is desired for each of the individual sites?
5. Integrations
A website doesn't usually exist in a bubble. It will often push and pull data from other databases or third-party services. Understanding what current and planned future integrations look like is critical to our scoping process, including:
Number of integrations - How many integrations do we need to plan for, complete, and QA? We consider an integration to be anything beyond just linking out to an external site or service.
Type of integrations - For each integration, does it push data out, pull data in, or both? Is the pulling of data session-based, cookie-based, or permanent (in the CMS database)? Are we completing the integration via API, chron jobs, pre-built JavaScript embeds, iFrames, or some other solution?
Documentation and developer friendliness of integrated systems - Are these integrations commonly used by others? Is it proprietary or custom-built, without documentation or the proper API endpoints?
Forms - What web forms exist on the site and where does that data go and live? Does anything need to happen on the site as a result of form submissions?
6. Features
Beyond the creation, editing, and displaying of content, what does the website actually do? This is by no means an exhaustive list, but some examples of more complex features include:
Dynamic maps - Maps that are navigable with data points or pins managed within the CMS.
User accounts - If there is a concept of logins and passwords and what these accounts enable (e.g., gated content vs. push/pull dynamic user functionality).
Ecommerce - Can visitors complete purchases on the site? Monthly subscriptions? Does this tie into user account functionality or stored information? What is the size and complexity of the product catalog?
As you can see, there’s a lot that goes into estimating the scope, scale, and cost of a website project. While we've explored various categories and factors that can help estimate costs and requirements, it's important to remember that the findings we glean up front are not set in stone. They simply offer a rough starting point that we can build off of. With a business-critical project like your website, it's essential to trust the expertise of an experienced team and leave room for adjustments along the way, because both parties know the least about the project in the process of estimating than you will at any future point of the project.
So, while a robust RFP can provide answers to some of the questions above, the power of conversation is invaluable. Transparent, open dialogue with potential partners will not only help you uncover hidden complexities, but allow for room to discuss how scope relates to your business objectives — which will help you get it right the first time.
