Statements of Work (SOWs) are a critical part of client work at any agency and play a big role in how projects play out. Here at Portent, we used to use a template-based SOW for our web development clauses but with this approach our development team ran into issues such as improper scoping, vague functional requirements, and occasional feature creep.

To combat these frustrations, our team realized a couple of years ago that we could apply the principles of component-based design, a powerful development ideology for creating websites and web apps, to our SOWs to create better protection for our teams, prevent scope creep, and be more organized.

In this article, we’ll cover why development SOWs are so important, problems with template-based SOWs, and how you can apply the concept of component-based design to create component-based SOWs that can improve the working relationship between your developers and clients.

What is an SOW?

Statements of Work (SOW) are essential for setting up a successful business relationship. They provide details of the scope of work, timeline, and the expected deliverables from all parties involved.

In this article, we are focusing on SOWs that have a development scope for website build projects.

Why It’s Important to Get SOWs Right

When SOWs are done correctly, they are an effective tool for managing expectations and ensuring that everyone involved is on the same page about the project and their respective roles.

When a SOW is not done correctly, it can lead to miscommunication and frustration between client and agency. If the SOW is too vague or does not properly cover the specific project requirements, it can lead to misunderstandings, scope creep, and delays.

The importance of getting SOWs right cannot be overstated. They are a fundamental first step of the business relationship and the bedrock on which the project starts. As such, SOWs should be comprehensive, clear, and specific, with lots of attention to detail.

Problems With Template-Based Development SOWs

For a long time, we used a template-based approach for our development SOWs. Template-based design and development is a method of breaking the website into a number of unique pages (or templates). 

For example, common templates may be:

• Homepage
• Blog hub
• Single blog page
• Services page
• Default internal page

While it is a simplified, easy-to-understand, and relatively uncomplex method, on some projects, it exposed us to vague requirements, scope creep, and scope underestimates.

For instance, let’s say a project calls for 10 templates. How can we properly scope the level of effort required for each template? What if a single template ends up being made up of 15 unique components? And another comprises of 10 unique components? With 8 other templates to account for, you can see how the complexity could explode rather quickly. Additionally, multiple templates often share multiple components, so there is less precision in scoping template-based development resources.

This is why at Portent, we shifted the way we write the development section of our SOWs. By looking at these problems through a developer lens, we created a new approach that is based on component-based design and development practices; This new method is a major step forward from previous iterations of development SOWs.

What is Component-Based Design?

For those unfamiliar, let’s first touch on what component-based design is. Component-based design is a software development method which emphasizes the compartmentalization of an application into individual, self-contained components (or blocks). The components are designed to be loosely coupled, meaning that they can be swapped out or rearranged without disrupting the overall application.

The idea behind component-based design is to allow developers to create an application solution that is adaptable to future changes and easy to build upon. Rather than starting from scratch, developers can reuse existing components and customize them to fit the application’s needs. This helps to reduce development time and cost while encouraging code reuse and flexibility.

Component-based design is increasingly popular in web development as it allows developers to create complex and dynamic websites quickly.

Component Examples

While we won’t dive into a ton of detail about components, the visualization below depicts a handful of components as broken down from the Portent homepage. Components can be:

• Main navigation
• Search icon/field
• Cover block
• Logo array
• Card with media, text, and CTA
• Buttons
• Carousel of content with image, text, and CTA
• CTA banner
• Blog post card
• Ebook card
• Footer navigation
• Social sharing icons

How to Apply Component-Based Design to Your Development SOWs

The benefits of component-based design for software development are apparent, so why not put that logic into our SOWs? Compared to the template-based approach, a component-based methodology for our SOWs is an obvious upgrade.

1. Break Down the Project into Components

First, create a list of all the common, known components for our project. For example, all websites need navigation, search, cards, and some kind of cover or hero component.

Next, define as many additional components that are specific to the client’s requirements. These could be things like a testimonial carousel, a comparison table, and/or a Google reviews component. It’s OK if you’re not able to define every single component in the SOW, as this can be finalized during the technical requirements phase early in the project.

However, be sure to specifically scope any complex, resource-intensive components as part of the components list in the SOW. Most components will be approximately the same level of effort, but some may break that mold. An appointment scheduler, a carousel with varying views depending on mobile or desktop display, and tabbed content are all examples of components that should be defined as a requirement in the SOW so they can be properly scoped by your team.

2. Establish the Max Number of Components

If you haven’t done many component-based design and development projects, you may be asking yourself how many components should a site have? The answer is it depends. Based on my experience at Portent, small to mid-sized sites will have 15-25 components, whereas larger to enterprise-grade sites will have 30-50 components.

All websites will have overlapping components or components that are necessary based on the nature of what is being built. Things like navigation menus, search functionality, content cards, buttons, and maybe CTA banners are examples of heavily reused components.

3. Define Functional Requirements

In addition to our clearly defined number of, or range of components, any additional functionality requirements are defined as a clear list of deliverables.

Some examples of functionality requirements that need to be defined alongside the number of components could be:

• User dashboard
• CRM integration workflow
• Custom event calendar and registration system integration (API)
• Google Maps location finder

Benefits of Component-Based Development SOWs

With a component-based approach for development SOWs, there is naturally more protection for your team, built-in guardrails for feature creep, and it’s more precise and organized.

Protection / Safety Net For Your Team

Component-based SOWs create a safety net because they provide a framework for creating and managing the scope of a project. By breaking a project down into components and specifically defining the max number of components, the scope of the project is clear. This builds protection into the SOW for your company for any large changes being asked for by the client once the project has started.

Avoid Scope Creep

Another advantage of component-based SOWs is avoiding scope creep. Scope creep is the gradual and unplanned expansion of a project’s goals and requirements beyond the original agreed-upon plan.

With our component-based SOWs, the deliverables list is agreed upon by both parties prior to the start of the project and serves as the basis for the entire project. Once the project is underway, any changes to the agreed upon list of deliverables must be discussed, negotiated and agreed upon before proceeding. This ensures that all parties are aware of any changes to the project scope and are in agreement on how to proceed. Avoiding ambiguity avoids scope creep.

Better Organization

Organization and precision are a natural result of a component-based approach to development SOWs. We’re getting more detailed with our list of components which further defines the project’s requirements. With all the primary functioning elements defined in the development section of our SOW, it creates a great resource for the development team and clients to reference throughout the length of the project.

Conclusion

At Portent, we adapted our approach to development SOWs by implementing component-based design techniques because it just made sense from an organizational, functional, and protection basis.

As always, be sure to heavily involve your dev team or team lead on all development-based SOWs. They should have an integral role in scoping functional requirements as well as breaking down approximately how much each component will take to develop.

We see the integration of component-based design techniques into development-based SOWs as a step forward for all parties involved: clients, the agency, and the development team.