15 best practices for managing your first (or subsequent) web development project | Social Signal

Back in the day, the only real way to have an online conversation was to build your own blog or online community. These days, many people, companies and organizations have their first taste of online conversation and social media through pre-established social networks like Twitter, Facebook or YouTube.

But eventually, you might outgrow what you can do with those sites alone, or decide you want to have a new kind of conversation that is best supported with an online community of your own. When that day comes, you’ll face the painful, terrifying and thrilling experience of building a website — if not with your own bare hands, then through the efforts of an in-house web development team or web development company.

It’s a process that is always challenging, but never more so than the very first time you undertake the job of managing or supervising a development process, even if it’s as a client rather than as a developer. You don’t know what to expect, you don’t know what questions to ask, and you don’t know who is responsible for what. So let me offer a very partial set of observations and insights into the development process, which may make your first time out a little less overwhelming — and which may help experienced web-heads refine their approach, too:

1. Developer hours are your new hard currency. If you’re managing a development process, you need to treat each developer hour like it’s a bar of gold. If this is your first dev process and you’re working with experienced developers (if this is your first dev process, I really hope you are working with experienced developers) then they probably cost your company or client somewhere between 2-5x what you get paid per hour. Unless you’re dealing with an infinite budget, that means you have to be careful about where you spend those hours and dollars — and even if the dollar constraint isn’t tight, you’ll find that a good developer typically has other demands and will offer you only so many hours, so use them wisely. Once you start seeing your development hours as very, very precious, a lot of other development principles follow….
2. You are supposed to be the bottleneck. One of the challenging aspects of the client or project manager role is that you turn into a bottleneck: there’s a steady flood of incoming tasks for the dev team, which you’re supposed to pass along, only you feel like you can’t feed them to the dev team fast enough. You’re the bottleneck, which we are told is a bad thing, so you feel terrible. But here’s the secret to your role in the development process: you are supposed to be a bottleneck. By slowing the rate at which incoming tasks flow to the dev team, you allow them to work on the priorities that have already been established. While you may need to feed them some occasional additional tasks, particularly after a period of testing, it’s your job to filter all those incoming requests so only the essentials make it to the dev team.
3. Ticket your tasks. Web development companies typically use tools like Unfuddle to track their outstanding development tasks including bugs that need fixing. If you’re working with a development team that will give you direct access to their ticketing system, you may find it easiest to feed your tasks directly into the system; most of the time, however, the dev team will want you to give them tasks in some other form, so they can enter them into the ticketing system with all the details they need in order to address the task correctly. But you can create your own de facto ticketing system by religiously writing each incoming issue down in a single place, using a consistent format that allows you to review all issues and prioritize the ones that will go forward to the dev team. I recommend doing this in a spreadsheet (if you want others to see what’s already on the list, use Google Docs) or using a task/project management system (like Basecamp).
4. Review and prioritize. If you’re “ticketing” all the incoming questions, bug reports and change requests in a single spreadsheet or task list, you can review that list on a weekly or daily basis to decide on which items will get forwarded to the dev team. (Weekly for most of the process, daily when you are in the final phase of quality assurance and launch.) The closer you are to launch, the higher your threshold for what gets prioritized: if you’re just a few days from launch, the only things that should be addressed are the 5-alarm fires.
5. Batch your questions, bugs and change requests. It’s very easy for a web development process to get overwhelming, if only due to the volume of email it generates. (A project management tool that includes threaded messaging, like Basecamp, can help a lot.) If you are relying on email to send requests to your dev team, try to limit yourself to one email a day unless you are facing a major emergency. Ask your dev team to do the same — to reply to all your questions in one email per day (or week), replying to each line item/question directly underneath that question, so you see that each issue is addressed (even if it’s just to say that the dev team has now added that bug to their ticketing system). (You may want to agree that they can reply to each ONE email from you with up to TWO or even THREE emails from them: the first email to answer all the questions they can answer off the top of their heads, the follow-up email(s) to address any outstanding issues that require further investigation.
6. Snap your glitches. Part of the secret to communicating with a dev team is communicating clearly about what problems you are having or what you need done. That’s a bit of a Catch-22 when you’re new to web development, because you don’t necessarily know how to describe what you are looking at. So don’t try — take a screenshot instead, and send that to the dev team in your next batch of requests/bug reports! Use a tool like Skitch, and you’ll be able to draw an error on the part of the screen that is puzzling you, or to write a short note directly onto the screenshot noting your concern. Just make sure your screenshot includes the URL of the page you’re looking at. (The easiest way to do this is by including the top of your browser in the screenshot.)
7. Google your problems. If you are doing hands-on work as part of the site development process, such as authoring or loading content, you may run into problems that could be bugs — or could just be things you don’t yet know how to handle. Before you ask your dev team for their (expensive) help, try googling your problem: if you’re getting a specific error message, google that, or if you’re just trying to figure out how to do something, google the task along with the name of the web tool you’re working in (e.g. “WordPress how to insert image in post”). Unless you are working with a custom-built or obscure tool, the odds are good that somewhere on the web, someone will have done an awesome job of explaining how to do the thing you are trying to do, or how to fix the thing you are trying to fix.
8. Give up quickly. The flip side of batching your concerns is that you know you will be in touch with your dev team every couple of days. So if googling your problem doesn’t yield a quick answer, don’t keep slamming your head into a brick wall. Add your question to the batch you will be sharing with your dev team later today or this week, and then set the task or problem aside until you send your next batch of questions and get the answers your need.
9. Define what constitutes an emergency. Talk with your dev team about what constitutes an emergency, so that you agree on what calls or emails simply can’t wait for the next batch. Normally that will include any issue that prevents users from accessing a significant part of the site (either because it’s a very important part, or a very large chunk) , an issue that produces a visible and embarrassing bug (like a huge missing image on your home page), or an issue that creates some kind of legal liability (like disclosing private user information). And agree with your dev team on how to reach them quickly if you do face an emergency: email? tweet? SMS? call? Whatever your communications mechanism, it should be a channel that can get a response in less than 1 hour anytime during business hours, and ideally well into the night. (But remember, that channel will only stay open and responsive if you are onlyvery careful not to abuse it. If you have “emergencies” on a regular basis, either you are too quick to call your dev team, or they aren’t doing a good job of keeping your site bug-free.)
10. Schedule a standing check-in call. Email is great, and project management software is even greater. But there is nothing to keep you in sync with your dev team like regular phone calls. Scheduling can be tricky, so set up a time for a regular weekly call or meeting as soon as your work gets underway, and increase that frequency to at least 2x/week (possibly even daily) for the last couple of weeks leading up to launch (those daily calls can be short, but can help to quickly address urgent issues). Keep a separate queue of issues to discuss during your next call, and take 15 minutes to prioritize that list just before you have your weekly check-in, so that your most important issues get addressed even if you run out of time.
11. Build a buffer. Just as your job is to serve as a buffer between your site’s users and your web team, you may find that you need a buffer between you and all those authors/users. Don’t feel like you need to address every single question or suggestion as it rolls in: set up an auto-reply if you must (“thanks for your email, someone will reply soon”) and then do a daily (or for smaller sites, twice weekly) review of incoming reports, feedback, info requests etc. Decide which of these should be transferred to the queue for your dev team (if any), which you can and should reply to in detail yourself, and which can either be ignored or get a non-personalized follow-up (“We’ve reviewed your suggestion and will consider it for our longer-term marketing plans.)
12. Pay attention to what your dev team says is easy or hard. This is a longer-term investment, but unless you are going into web development yourself, the most useful thing you can know about how to build websites is what’s easy and what’s hard. That varies substantially from platform to platform and even version to version, but if you think you’re going to be working with the same web development tools or content management system in the future, it’s worth learning about what is easy to fix and what’s complicated. This is not intuitive, since things that often seem incredibly simple (changing wording on a field, adding a checkbox to a form) can turn out to be very tough, and things that seem hard (adding a rating system, displaying related tweets) could turn out to be incredibly easy. The more you listen to what your dev team says is easy or hard, the better you’ll be at prioritizing items during future dev projects (because you’ll know to prioritize easy-but-important tasks over hard-and-important ones).
13. You will not get it right. Even if you take all the foregoing to heart, your website (and especially your first website) will be full of shortcomings — if not outright errors and bugs. That’s not a sign you’re doing it wrong: it’s a sign you’re doing it right. If you waited until every last problem was fixed, you’d never launch. Better to get your site up on its wobbly legs as soon as possible –to “launch crappy”, as we used to say — and to start learning from your users before you invest any more money in building functionality they’ll never use, editing pages they’ll never look at, or fixing glitches they’ll never notice.
14. Get a mantra. When we were building our very first client website, our client gave us a crucial piece of advice: iterate. In other words, get it done, get it live, and start learning. We printed out that one word — ITERATE — and plastered it on the wall of our office as a touchstone. Choose the touchstone that will help you remember that you’re not trying to build the perfect website, and put it where you’ll see it every day.
15. Enjoy. One of the things my non-web friends often say they envy about my work is that I actually make stuff. This used to seem kind of funny to me, because I grew up in a world where making stuff meant actual physical stuff like cars and clothes. But with so many of my friends working in professional fields where there is truly no tangible work product — just ideas shared, organizations improved, people made less neurotic — I’ve come to see the miracle of a job that actually creates a visible outcome that other people can visit, experience and participate in. Looking at the site you’ve been part of and thinking, hey!! I helped to make that!! is almost the coolest part of building your own social website.

But not quite. Because the actual coolest part comes when your part is done, at least for now, and all those community members start moving in and posting content and talking and actually using this thing you thought you built. Because that’s when you realize you didn’t actually build a site at all: you built an invitation. And now other people are accepting that invitation, and using it to build something far more personal, meaningful and alive than anything you could ever have imagined.

What bits of wisdom would you pass along to someone working on a web development project for the first time? Please do share your thoughts in the comments below, or tweet them and link to this page in your tweet.