Whether you're rebuilding a legacy website, or developing new, bleeding edge applications, all projects are composed of at least three essential components. Whether intentional or unplanned, no venture leaves the napkin without these essential ingredients:
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 is absolutely critical to success. 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 at least be roughly gauged by individuals who are not full-time strategists or art directors. Development is different.
I hope to shed light on what non-coders often see as a dark art by revealing tips on how to estimate the scope of development work before the budget gets blown. As a web developer, I'm all too familiar with "scope creep". It's an avoidable plague that has claimed oh-so-many ambitious endeavors and is frequently caused by over-expanding development goals. I've distilled my years of personal development experience into three helpful nuggets for anyone looking to survive on the web:
1. Know what you want. Perhaps the most frequent cause of projecticide (I'll take the credit coining that) is failure to communicate all of the goals. This is hardly caused by incompetence, but is the result of incomplete expectations. For example, project administrators often don't realize that they need a search feature until significant development has already taken place. Depending on the application, it could be a significant workload to retrofit the code to support search. This kind of attention to detail makes a strong case for having excellent project architects 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 blowing the budget, while seemingly challenging tasks can be accomplished in minutes.
When developers examine all the features a project will contain, they are able to judge how challenging a given site will be. We’ll call this the scale of complexity. 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 basic web-project: a static brochure website. Each of the following "features" would increase the project’s scale of complexity by a significant margin:
Dynamic pages: Is your website content managed (can you edit it)?
Permissions: Does your project have different permission levels for editors?
Public Users: Does it offer online accounts for site users?
E-Commerce: Do you offer products for direct sale on the site?
Apps: Does your website provide a service or task to your visitors?
Unique Interactions: What user interactions are unique to your website?
Hosting: How do you plan to host the site?
Depending on the project, one or more of these features may be necessary. Since each will significantly increase the scale of complexity, be sure to adjust budgets and timelines accordingly.
2. Move on. Refreshing your website? Let go of the past. A good rule of thumb for the fast-paced 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. It can actually save your budget and, more importantly, improve your 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, be sure to communicate that to your development team, as it will likely increase the scale of complexity once again.
3. Build a system, not pages. This point is both philosophical and practical. Good content-managed websites are systems, not pages. Let me explain. 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. While the simplicity may have been convenient, it was very difficult to maintain. If someone wanted to add a new menu item, they had to edit every single file in the website. It also caused each page within the website to have a slightly different layout and structure, which confused users.
The solution is a computer program (system) where the outputs have the same essential layout but different content. Not only does this make the website more maintainable, but it helps the site visitors understand the context of your website. However, the philosophical implications of system-think go far deeper. Architecture, design, and content strategy should be approached from a system perspective. For example, wouldn’t you want your articles to sound like they come from the same or a similar voice?
Back on the development side, the quicker your team learns to think of your site as a system, the better for your developers, the budget and the site users.
Hopefully these tips will help you navigate the dark waters of development on your next web project, and prevent runaway budgets in the process.