Redesigning and rebuilding a website is a lot like remodeling a house. When you begin a remodel project, you don’t always know what challenges you’ll find until after you’ve ripped up the floors or torn down a wall. If staying on time and on budget is important, then planning and communication are the most important elements of your web project management toolkit.
Here are a few areas that can hide surprises when launching a web development project and some suggestions to mitigate surprise.
The Antiquated Website:
Older websites may have a brittle architecture if they were not built to web standards (that’s why web standards were created). Every time you touch one small thing something else breaks or looks wonky in unpredictable ways. “Spaghetti code” makes it difficult to make easy updates.
The website might be built on top of proprietary code that you can’t edit which means that over time you’ve probably cobbled together new functionality you’ve had to build and integrate into the interface. This becomes a maintenance headache.
Sometimes site owners want a design update but they think they can save money by not updating the code. I’ve got news for you. Modern websites look and feel good because the code looks and feels good. It often ends up being cheaper to build a new design in modern markup and code rather than trying to make old markup and code do modern presentation work.
If the web application is more than a couple of years old, hasn’t been updated and wasn’t built for ease-of-maintenance, it may be less labor intensive (i.e. less expensive) to plan for a rebuild.
If you’re uncertain of this, ask people bidding on your project to provide a comparative estimate for rebuild vs. refresh.
And last point to make about the case of an antiquated website is that to get an accurate estimate, you may need to give the potential consultant access so they can pull up some floor boards and evaluate effort.
Licensing:
License management and asset tracking software are common tools for IT managers, but for websites, unless they are very large, not so much. So outdated or overused licenses are often not discovered until a redesign project happens. You might want to audit the website for paid components for 3 reasons:
- To include them in the budget
- To ask project bidders to suggest lower cost or free open source alternatives
- To renegotiate your licensing agreement if it’s up for renewal.
Other licensing areas that are often neglected:
Professional fonts: fonts need to be licensed properly so we can use them as web fonts.
Another often neglected licensing piece is worldwide usage rights to modify your website or application from your former developer. The SemioticPixels contract assigns rights to the client to keep everyone in the clear, but many web developers do not include this. This is especially important if you’ve hired someone to build a custom application such as a mobile app. Make sure your original contract does not contain language requiring you to use your last developer to make changes.
Plugins and other web elements that you paid for when you initially built the website need to be maintained and updated. If you’re updating your CMS, it’s pretty common that paid plugins also need to be updated and will have an associated upgrade fee.
Cracked Websites:
I actually see a lot of websites that nobody noticed were hacked. While many website hacks are noticeable because suddenly you can’t log in and you’re receiving spam complaints from customers, the most successful hacks are more subtle and can go unnoticed for a long time if no one is paying attention.
If no one is monitoring your server usage, logs, or unauthorized file changes you may not know your website or server has been hacked until someone begins to dig into the code and discovers weird obfuscated code snippets embedded in random files. Or worse, weird code at the server root.
At this point, it’s nearly impossible to identify the source of the hack and the only real option is to change all passwords, reinstall the CMS from scratch, rebuild the server if it’s not on a shared host, and do our best to scrub the database. And set up monitoring tools that will let us know if it’s hacked again.
Not all hacks come through your website. Over the past year, I’ve fixed a number of sites that were hacked repeatedly from a compromised web host. If you use a shared web host, it’s a good idea to set up google alerts or monitor discussion forums to learn of any issues as early as possible. They won’t send out a mass email declaring that they’ve been hacked unless there is loud enough public outcry and by then the damage is done.
A Project Plan:
A schedule of deliverables and the team or persons responsible can go a long way to helping the project along by clarifying roles and responsibilities. Don’t forget to clarify user acceptance testing and at what point we call the project done. This should be part of your contract with your development team.
A Communication Plan for All team members:
You can save a lot of project management overhead by introducing everyone involved early in the project and establishing a communication plan. This way, your design team, development team and system administrator can clarify details quickly.
When you’re ready to finalize the design, ask your developer to review it for completeness and to give ballpark cost estimates before signing off. Often, your development team may offer feedback that will save your budget in production.
Also ask your development team to outline a server requirements document to ensure their solution is compatible with your hosting resources. Even if your development team will also be providing web host services, it’s still good to articulate hosting requirements so that you are clear on the ongoing budget impact. In a best case scenario, your hosting requirements should be part of your scalability plan (see below). In other words, you should have an idea of the traffic load limitations of your hosting at launch so you know at what point you’ll need to increase your hosting resources.
Scalability:
I believe that every website should have a scalability strategy no matter how small the site. I believe this because I’ve spent days of my life without sleep, scaling small websites quickly for happy events such as being featured on Oprah, or a sudden “Slashdot effect”.
We all hope that our websites will become popular, but not having a plan in place for managing a sudden burst in traffic can be a real business opportunity miss.
Not only will a scalability plan give you peace of mind because you’ve already made the big decisions, but you’ll also have a ballpark budget to help you decide at what point to implement the scalability plan.
When you’re in the thick of it you don’t want to be distracted by trying to keep your website live. You need to focus on your business opportunity.
Budget and Price Negotiation:
There is this old sales mythology that whomever throws out a number first loses. I disagree completely. Negotiating price is not a game of winners and losers.
You have a budget and I have a time estimate. You give me a budget and I’ll tell you what we can get done within your budget and how we might stage your project to meet your budget needs.
In a service industry such as web development, building long term relationships has greater value than competing for price and I’m going to work within your budget in order to build that relationship. It really is that simple.
RFP Writing and Receiving Accurate Estimates:
It is in your best interest to receive accurate estimates, and it’s in your development team’s best interest to deliver accurate estimates.
Since responding to a Request For Proposal (RFP) is usually not billable time, many web developers and web development firms are somewhat judicious in which RFPs to invest their time.
If your RFP is well written, you are more likely to receive estimates from higher quality web developers who want to invest in the success of your project.
You should include the draft design comps with the RFP in order to receive a realistic and complete estimate. That way there are fewer, if any, surprises for you, and your developer will feel more confident in giving you a capped ceiling estimate if you ask for it. To avoid hidden costs, when you are evaluating estimates, look for transparency and true total cost estimates, not just the lowest price.
If the estimates you receive back are wildly different, you might want to revisit the details of your RFP or hire a consultant to help you write the website development RFP. If your project is business critical, you might also consider using a consultant to assist in evaluating responses.
I hope that’s helpful. These are just some of my own experiences. Please feel free to share yours!