A Better Budget: How Tech Planning Improves the Scoping Process

One of the toughest parts of any web project is estimating how much the project will cost and how long it will take. This is especially true for projects that build something custom or new. 

There’s a reason this is difficult: websites aren’t one-size-fits-all. There are too many variables involved. At Blend, we often compare the web process to building a house. You wouldn’t call a custom home builder and ask, “how much for a house?” because there are hundreds of questions — big and small — that come first. Where do you want to build? How big will it be? How many beds or baths? Will the floors be vinyl or granite? 

Both home builders and web shops solve this problem through a process of consultation and discovery. They find out needs, work up a blueprint, and begin estimating based on real information. For a home builder, this information includes size, location, and fixtures. For a web development shop, this includes the complexity of templates and integration needs.

For a home builder, this might be wrapped up as a blueprint. For us in the web industry, this is called a technical plan.

Defining the purpose of the technical plan.

For a website, the technical plan begins as a description of the client’s needs and expands over time to describe how a development firm will meet those needs in detail. 

The goal is to create a document that’s descriptive enough for clients to understand how their site might work, while providing enough detail to answer the development team's questions during estimation and build. 

For CMS-driven web projects, Blend has developed a standard technical plan template. A typical plan will have sections for: 

• Goals: We describe the purpose of this project. How will we know it’s a success? How will we measure those goals?
• Behaviors: We then describe how any special functionality for the solution will work. For CMS projects, this section describes features that aren’t normally part of the CMS through the use of user stories.
• Surround and Navigation: Every website has an overall style and navigation structure aligned with its content. We document this independently of the pages.
• Page and Block Types: Most of the development on a CMS is the building of pages and blocks (or components) to enable easy maintenance of content. We document the names of these and how they’re structured.
• Site Features: During the build process, we’ll make a lot of decisions on features like authentication, redirects, and meta fallbacks, just to name a few. We capture these decisions in this section.
• Integrations: If a site ties into an outside system, it’s important to keep track of how those systems connect, who is responsible for what pieces, and how the site should behave if one of these systems goes down.

During the creation of this document, the project team will read the described features, ask questions where needed, and provide estimates as to the complexity of the work and the time required. This allows us to base estimates on real engineering plans instead of vague guesses. The plan then becomes a guide for the project team during implementation, just like a blueprint.

How does Agile fit in?

At first glance, this process feels more like an artifact of “waterfall” development methodology, in which teams tackle every phase of a project one step at a time. This raises the question — does this technical planning process have any place within the far more common and preferred Agile methodology, in which teams fully deliver a piece of the project and gather feedback? 

Blend still uses an Agile approach, but with some caveats. Agile serves primarily to prioritize the efforts of an on-staff development team as they iterate over and over on in-house solutions. The only defined endpoint is when everyone agrees it’s “perfect.” Unfortunately, as a consulting agency, we’ve never encountered a client that’s willing to spend infinite time and budget. 

So we meet in the middle. In a waterfall approach, a requirements document is set in stone once it’s approved. However, our technical plan is designed to evolve and is updated as project requirements change. It’s essentially a way to test ideas on paper before they’re set in code. We still work with a largely Agile approach, but because we have a defined starting point, we can see the impact of decisions throughout the project on our timeline and budget.

Beyond a single project.

Once we have established a common method for planning and estimating, we can also reap the rewards across projects by re-using features, components, descriptions, and estimates from existing projects. We can continue to refine our documentation and our approach every time we implement an idea similar to one we’ve had previously. 

For example, if a client’s site needs to include a blog, our technical planning process doesn’t require us to reinvent the wheel. We’ve worked on dozens of sites with blogs, which gives us a baseline with which to develop the technical requirements — and the time needed to create the actual feature — giving us more time to focus attention on the unique areas of each site.

Getting it right.

We’ve developed this approach over time because we’ve seen how important it is to get it right when it comes to timeline, features, and budget with a web project. Our clients come to us with the expectation that we will stay as true to our word as possible. 

There are agencies similar to ours that are happy to take a wild stab at a project’s timeline and budget in order to land the deal, knowing they’ll need to go back later and tell the client that they can’t deliver within their original scope. 

We’re just not comfortable with that. We hold integrity as one of our core values, taking wild stabs doesn’t lead to great results for our clients. Our approach tends to take a little longer up front, but allows us to deliver on time and on budget.