Getting Unstuck: 6 Keys to Avoid Website Project Hell
Way too often, these projects are mired in problems and hardships right out of the gate. The tremendous risk when it comes to budget, timeline, staff resources, and board expectations puts a burden on the entire organization.
What should be a joyous and fun time—planning, designing, and launching a new website that will make everyone happier and more effective—becomes a nightmare. The entire organization gets bogged down and there’s no clear way to just finish the damn thing. Everyone feels stuck.
This, my friends, is what we call Website Project Hell.
But, it doesn’t have to be this way. Website projects can sometimes be challenging. There’s no doubt about that. But they don’t need to be hellish.
In general, projects that enter the hellzone do so not because of the specifics of that project. It’s not that the work itself is too difficult or that the team is being too ambitious, per se. Most often, it’s caused by the mindset of those involved in the project.
Author Michael Port put it aptly when he said, “many business problems are personal problems in disguise.” For nonprofit technology projects, I would rephrase it to say, “many technology problems are people problems in disguise.”
People are at the heart of every technology project. And ultimately, the mindsets and attitudes of the people involved in a technology project determine whether it succeeds with flying colors, or descends into the hellzone.
Let’s discuss some of the ways that your organization can shift their thinking and their approach to website projects in order to maximize its chances of success.
1. Put someone in charge
For any website project, there should be one person at the nonprofit put in charge of making decisions. They become the first point of contact and have the final word on what gets done.
This may seem obvious, but often the biggest blockade to a project’s success is the fact that there’s no clear line of communication. There’s no one person to collect the feedback of other stakeholders, distill it down into actionable steps, and make the final decision.
We’re, of course, happy to have meetings and discussions with additional stakeholders. But when there are questions that need answers or decisions that need to be made, there should be one person who is in charge of making sure that it happens.
If your project is run by committee, it will create bottlenecks and infighting that can drag down the entire process.
2. Define goals, not features
At the start of every new website project, we take nonprofits through a website strategy engagement that helps them understand how their website fits into the mission of their organization and what it needs to accomplish for them.
Often, projects get bogged down by a laundry list of wishful features and functionality, which may or may not be tied to the ultimate use of the website.
But if you start with the specific goals of the website from various stakeholders, then you can synthesize those points into features that are necessary in order to meet those goals.
This way, rather than getting tied down by small details, you’re able to focus on the big picture and how the website will meet the needs of your organization.
3. Prioritize and compromise
Given limited time and resources, it’s often necessary for nonprofits to prioritize and sometimes compromise on what their website can ultimately do.
This isn’t as difficult as it may seem.
Rather than having some kind of arbitrary selection process for what will be included and what will not, give stakeholders a list of proposed features and functionality. Then have them rank each according to their priority for the work that they do. Combine the scores and rank all of your proposed features from those with the highest level of overall priority to the lowest.
This will give you a clear roadmap of what parts of the site are critical across the entire organization and which ones could be more easily put on hold if time or budgets won’t allow for them to take place in the initial build.
4. Do your due diligence
Another common misstep is for nonprofits to assume that their website will basically be exactly like their old site, but with a different look.
This may be the case in some instances, but it shouldn’t be the default view.
If you’re taking the time to build a new website, you should also take the time to analyze the website that you currently have, perform an audit of the content, and be strategic about which pages are carried over to the new site, what new pages can improve your site, and how they should be organized to improve usability and navigation.
I won’t go into all of the details for this kind of an audit now. But, you can use a tool like Google Analytics to see data on which pages are most popular (or least popular), how people navigate your site, and what information they might be searching for.
Use data to guide your planning and decision-making process.
5. Choose the right technology
One major way to set back your website project is to choose technology that’s popular or pretty but doesn’t fit the needs of your organization.
This is a critical decision that will not only affect the features and functionality of your website but will also have a lasting impact on your team and how they manage or administer the website.
You need to carefully consider your options and choose the best CMS, CRM, and other technology that provides the level of usability that your team needs to keep the website up and running. Then, select a vendor with a strong track record in implementing that technology.
Many organizations get stuck with a website that’s pretty, but not very useful because their chosen vendor did not have significant experience building that type of website. We see this more often than we like when talking with nonprofits who are frustrated with their current site.
We use Drupal because we are experienced with it and find that it fits the needs of many nonprofits that we work with. But, that doesn’t make it the right fit for everyone. You can’t fit a square peg through a round hole, so make sure that you start off with the right tools to achieve your goals.
6. Plan for the long-term
Many organizations think of their website as a one-and-done project.
Every 5 years, you go through a grueling process to overhaul the whole thing. Then, you sit around as the frustration slowly builds as it no longer meets your needs.
Don’t fall for the trap.
Think of your website like a house.
It will require some routine maintenance to keep it in the same condition as when you bought it. But, more importantly, you can improve your house over time without having to tear it down and start from scratch.
Rather than allocating all of your funds for one big website project every few years, spread out that investment to make incremental improvements and upgrades over the course of that same time period.
Not only will your website last longer before it’s in need of major renovations, but your staff won’t have to suffer for years as the website slowly deteriorates in functionality.
Once you reframe your entire website as an ongoing project, rather than a one-time outlay, it’s easier to prioritize and make compromises where necessary to move forward.
If your team is able to adopt this mindset and keep in kind these other strategies, you’ll be lightyears ahead on avoiding the kinds of problems that often suck the lifeblood out of a website project.
Keep in mind that while it may be stressful, this entire endeavor should ultimately be rewarding. You should walk away feeling happy and confident about the outcome of your website. And it should help your organization grow and improve.
The topic of who is financially responsible for fixing bugs on a software project is a question that often comes up during the lifespan of a website. Especially if you don’t have an extensive background in website development and support arrangements, it can be hard to determine what’s “normal” and reasonable in this type of situation.
Defining clear roles and responsibilities is an often-overlooked element of a successful website project. With complex and technical projects, such as those built on Drupal, the need becomes even greater when key stakeholders may not have a complete understanding of the details of the work being performed.