Web Development in the Deep End

Avoiding “scope creep” and keeping your project on budget

Whether you’re rebuilding a legacy website or creating a bleeding-edge application, you’ll need to mull over architecture, design and development.

Architecture is typically the most undervalued of the three. Understanding your target audience, organizational stakeholders, true versus perceived goals, and then setting metrics for success are all absolutely critical. The stronger the strategy, the more successful the product.

Design, contrary to popular opinion, is so much more than color schemes and page layouts. The web is not a static canvas. Users expect fluid, interactive and instantaneous experiences. Meeting, if not exceeding, those expectations falls into a designer’s hands.

Despite the expertise it takes to execute these two disciplines, architecture and design can be roughly gauged by individuals who are not full-time strategists or art directors.

Development is different.

Often seen by non-coders as a “dark art,” development can be a mystical process to many. Confusion about how software is written can lead to budgets getting blown.

As a web developer, I’m all too familiar with technical “scope creep.” It’s an avoidable plague that has claimed many ambitious endeavors and is frequently caused by ever-expanding development goals.

I’ve distilled my experience into three nuggets for those managing web projects who want to survive — and thrive — through the development process.

1. Know what you want.

Perhaps the most frequent cause of projecticide (I’ll take the credit for coining that) is failure to communicate all of your goals. This is not caused by incompetence but rather by incomplete expectations.

For example, a project administrator may approve a site architecture and design comps that don’t include a search feature. When the omission is noted, the team building the site may receive a casual, “Oh, and can you just make sure there’s a search feature too?” Whoops! Adding search may not be so trivial. In fact, depending on the technologies used in development, it could require a complete rethink of the application structure. Avoiding this kind of conundrum requires excellent project architects on your team who can point out — in advance — that your project will struggle to meet its goals without a search feature.

A single website may contain hundreds of features. Each of those features takes time for a developer to write. What appears to be a trivial task to a non-developer may end up obliterating the budget, whereas seemingly challenging tasks can be accomplished in minutes.

When developers examine all of the features a project will contain, they are able to judge how challenging a given site will be; call this the “scale of complexity.” If project administrators could roughly determine the scale of complexity in advance, this could prevent project overruns.

“If project administrators could roughly determine the scale of complexity in advance, this could prevent project overruns.”

Let’s pull back the curtain on how developers make those judgments. Consider a simple project: a static brochure website for a restaurant. Once development has begun, any of the following requests would increase the project’s scale of complexity by a significant margin:

• “Oh, and I need to edit the menu page daily.” Whoops, the website was built with a static site generator; it will need to be ported to a content management system.
• “I want Jane to be able to edit the menu but not the homepage.” Yikes. Tiered permissions definitely increase the scale of complexity.
• “Let’s let visitors order takeout from our online menu.” Uh-oh. Do you want to offer products for sale on the site? That alone could double the hours required to build a “simple” project.
• “Great job building the new site. Feel free to ‘flip the switch’ to go live now.” Of course. But have you considered deployment and hosting?

Depending on the project, these may be necessary, and because each will dramatically increase the scale of complexity, be sure to adjust budgets and timelines accordingly.

2. Move on.

Refreshing your website? Let go of the past.

“If something worked in the past, it’s likely that it won’t continue to work in the future, and if something didn’t work in the past, it really won’t work in the future.”

A good rule of thumb for the internet is this: If something worked in the past, it’s likely that it won’t continue to work in the future, and if something didn’t work in the past, it really won’t work in the future.

Work with your content strategists and architects to avoid creating a 1:1, page-per-page port of your old site. Use a migration as an opportunity to refresh and cull your content. It can actually save your budget and, more importantly, improve your site’s quality.

If your old site has content worth keeping alive, consider creating an archive of your website. If all of your legacy content needs to be migrated, communicate that to your development team because it will likely increase the scale of complexity.

3. Build a system, not pages.

This point is both philosophical and practical. Good content-managed websites are systems, not pages.

“Good content-managed websites are systems, not pages.”

In the days of yore, when someone wanted to create a website, they created a slew of HTML files and placed them on a public server. Each of those files was a webpage, and the collection of the files made up the website. The simplicity may have been convenient, but it was very difficult to maintain. If someone wanted to add a new menu item, he or she had to edit every single file in the website. It often led to each page having a slightly different structure, which confused users.

Today, software generates each page for you (often called a content management system). This allows you to have the same layout with different content. Not only does this make the website more maintainable, but it helps the site visitors understand the context of your website.

The philosophical implications of system-think go far deeper. Architecture, design and content strategy should be approached from a system perspective. The quicker your team learns to think of your site as a system with atomic parts, the better outcomes you’ll see for your developers, the budget and the site visitors.

Consider these principles as you navigate the dark waters of development on your next web project — and prevent runaway budgets in the process.

For more from Journey Group, sign up for Story Matters, an email digest celebrating the art of storytelling in all its many forms.