Questions to Ask Before Starting a Project

We’re all human, and we all make mistakes and overlook important details sometimes – but the thing I can’t stand is making the same mistake twice. To prevent making the same mistakes twice, I have an ever-evolving list of questions that I use to create the tech brief for new projects.

In the hopes that this saves you some of the headaches I’ve had to suffer through, I’m making my list available to you. Some of these questions don’t have yes-or-no answers, and require additional discussion – but that’s okay. The point is that they were asked in the first place, and you’re including them in your plan.

Every time I start a new project, I run through this list of questions with the project managers or client, one by one, until I have all the answers I need – and after every project, I revisit this list of questions to see if there is anything I should have asked up-front that would have made the project go more smoothly.

Yes, this is long. But better to spend the time asking questions now and save yourself days or weeks worth of work later. Also, there may be whole sections you can skip entirely if they don’t pertain to your project – just be sure they really and truly don’t before you give them the brush-off.

I will be out of the country for a week in Belize starting oh-my-god-o’clock tomorrow morning, so this post is my gift to all of you who are stuck working on projects while I’m on a beach in Belize sipping Mai Tais. Enjoy!

Basics:

What is the main purpose of this website? General overview, specifically addressing goals the website or application hopes to accomplish. Online sales, brand reinforcement, etc. This answer doesn’t have to be long, but I find it helpful to include them here so that the tech process always compliments and enhances achieving those goals.

How “big” is this project? This is a generalized question and doesn’t require specifics most of the time – is it a 4 page site, a 40 page site, or a 400 page site. This helps to understand the basic scope. The answers to this question should include:

1. Approximate number of screens/pages in the website/application
2. What are the basic functions of the site? i.e.Registration, Game, Ecommerce, Search, catalog, photo upload, discussion boards, voting, etc

What data will be stored/accessed locally? Will the website/application require a database? You don’t need to make a concrete decision about what kind of database at this stage – just knowing there needs to be one is enough.

How will the site be updated?

1. Will it require a CMS?
2. What content is dynamic vs static?
3. How frequently is the data updated (hourly, daily, weekly, monthly, periodically)?
4. Where will the data come from? (client or administration back-end of any kind)
5. Who is responsible for updating the data?

What are the reporting needs?

1. Basic site traffic?
2. Will it require content‐specific reporting? (i.e. how many new users signed up between specific dates, etc.)

Will there be a mobile/WAP component? The answer to this question is usually “no” for the projects I work on, but it’s important to know in advance. Phone browsers these days are so similar to desktop web browsers that creating a WAP version of a site is far less trouble than it used to be, when you had to take black-and-white screens into consideration, etc.

What operating systems, browsers and browser versions are we targeting? Do we care about IE6 or other older browsers (pleasesaynopleasesaynopleasesayno)?

Are there additional considerations such as printer‐friendly versions, BOBBY/ADA‐compliance, age verification or other that we need to be aware of? Make sure you’re familiar with the COPPA-compliance guidelines before you create a site or application that asks for user information and doesn’t screen for the user’s age.

Domain Name & Hosting:

Where will this application/website be developed? If it will be developed on a different machine than its final hosting situation, we must provide time for file transfers, additional QA once the site is moved, etc.

Where will this application/website be hosted? If we are hosting, will it require a dedicated host, or virtual hosting environment?

If the client is hosting, have we confirmed that their server supports the technology we intend to use? This is a key point, but one that is often overlooked. If you’re expecting PHP on a Linux server and the client has an IIS box without PHP or MySQL, you need to know that up-front, so you can decide how to handle it. Maybe the client installs PHP and MySQL, or maybe you do the application in ASP – either way, the answer here has a huge impact on how you proceed, before even a line of code has been created, so you need to know that right away.

Also, if possible, try to obtain access to the hosting server as soon as possible, so you can run some basic configuration tests. One follower on Twitter remarked that the client confirmed that they had PHP and MySQL (on IIS), but the environment was not set up to allow PHP to talk to MySQL. Not something that’s impossible to fix, but if you’re pushing it close on your deadline, you want to know that right away so you can have the hosting company make whatever changes you need with plenty of time to spare. A simple phpinfo() would have spit out everything you needed to know (not to rub anything in, @derekobrien!). To be fair, I might have just assumed the same way he did, so it’s important to remind ourselves to check everything up front.

I would imagine that hosting blunder (and that was a blunder – who sets up PHP and MySQL but forgets to allow them to talk to each other?) is hopefully uncommon, but if you’re using libraries or modules like PEAR, cURL, imagemagik, the GD library, and so on, you’d best confirm that everything is all set up before you move forward.

In @derekobrien’s case, they weren’t granted server access until last minute, so he was caught off-guard by this. One way to protect yourself against issues like this is to set clear milestones in the tech brief or feature scope that you create based on these questions (which the client signs), with the caveat that if the client doesn’t provide server access by xyz date, the launch date can and will be pushed back, and additional budget may be required to get things up to snuff.

@derekobrien also included a clause in the fine print that says “If your server admin is a fool we reserve right to point and laugh at you.” I generally consider that implied, but it’s just as good in writing 😀

Will it require its own domain name?

1. If yes, will the client provide, or will we?
2. If yes, we must allow time for propagation
3. If no, at what url will this live? (sub‐domain of noise, sub‐domain of primary client domain, etc)
4. If sub‐domain of client, we must provide time to work with the client’s IT dept to configure DNS settings

Will we need to manage any email accounts for the project? If so, what are the account names, and are they pop3, IMAP or forwarding accounts? Who will be checking them?

Will this project be migrated to the final hosting location from an existing location? If so, a migration plan (including e‐mail address, DNS, content, database, etc migration should be created.)

Is this project ongoing, or for a limited time? If for a limited time:

1. What ongoing service or support will be required? Webmaster support email? Unsubscribe administration?
2. What is the plan for the domain name and/or website once the project is over? Do we keep hosting the project? Do we let the domain name expire, or simply redirect it to the main client site?

If the project is hosted on a server we are managing, server setup should include:

1. Realistic bandwidth estimate. We should confirm with the hosting company we select that if we surpass anticipated bandwidth, there will be no interruption in services. (Extra charges will apply, but service should NOT be suspended for bandwidth issues.)
2. Maximum throughput configuration available. There is generally an insignificant additional monthly charge for this.
3. If the project relies heavily on mySQL, we should consider making adjustments to the my.conf file to tune the database configuration for optimal settings. (I.e. if the database queries are largely SELECTs, optimize for SELECTS, etc.)
4. Fine‐tune the apache httpd.conf file to allow for maximum concurrent connections

Backup and Restore – if we are hosting the project on a server we manage, dedicated or virtual, some level of backup must be implemented for every account.Backup should include files, user data, and applicable databases – and a restoration plan should be created, should catastrophic system failure occur. The backup process MUST be tested during non-emergency circumstances. An untested backup is no better than no backup at all.

Flash/Video:

Will there be substantial flash or video aspects to this project? If yes, we should consider hosting arrangements and ensure we have the bandwidth available and ensure the throughput is set up to handle maximum traffic.

If the primary site or application content is Flash‐based, we must budget time to create an SEO‐optimized version of the page in plain text. Copy will need to be obtained from the client, and MUST accurately reflect the true content of the Flash. Attempts to keyword bomb or deceive search engines will result in being blocked from the search engine altogether.

Email:

Will the application or website be communicating with users via email or text messages? If so, we may wish to consider outsourcing email/text messaging for ease of management and to circumvent potential SPAM blacklisting issues. This decision needs to be made on a case‐by‐case basis.

Integration:

Will the application or website be required to interface (push or pull) with a third party system or service? If yes, documentation on the integration should be obtained at the beginning of the development planning so any potential obstacles can be addressed.

User and Content Filtering:

In projects where users will be contributing or creating content using the tools we develop, is there a need to build in support for:

1. Banning or blocking specific users by username or IP address?
2. Moderating content before it is displayed publicly or at least the ability for and administrator to delete to unapproved content to remove it.

If yes, by what method will offensive material be flagged as offensive? Does the application require a “report this content” function, and if so, what needs to happen when content is flagged? Who is notified, and what actions do they take? Should the system automatically unapprove content that is flagged many times?

Scrubbing or filtering bad words. If yes, what action should be taken if an offensive word is found? (i.e. is the offensive word replaced with ****, is it rejected by the system, etc.)

Pre‐Existing & New Content:

Does this project require us to import existing client data or content into the application? If so, in what format will the client be providing this data? (Excel, csv, Word, etc.) Adequate time must be allowed to scrub the data and create custom import scripts, and then to QA the imported data.

If content being provided runs on a timeline (such a daily quiz, where a new question is presented every day), do we need to set up an alert system that notifies an administrator if content is about to or has already run out?

Will there be ongoing new content that would be appropriate for use in an RSS feed? (Events, articles, blog content, etc.)

User Support:

What options does the user have if they have experiencing a problem with the application or website? Is there a Help/Tech FAQ page, a contact page, or some other way that they can reach out to us for assistance? What email address should be used for replies?

If we are going to be sending the user emails or text messages, we should outline the nature and frequency of this communication very clearly on a page available to the user.

A privacy policy should be built into the site or application whenever we are collecting any information from the user.

How does the user opt out? We should make it very easy for a user to globally opt out of our communications. Where applicable, on the opt‐out form, we should ask the user why they chose to opt out so we can better tailor future communications. Any email or text communication should require a double‐opt‐in confirmation.

Statistics & Reporting:

What aggregate statistical reporting needs to be done on this website/application? (Omniture, Google Analytics, Refresh Analytics for FB apps)

Do we plan on implementing click heatmap technology and/or multiple page versions for conversion rate evaluations?

Marketing and Promotion:

1. What media is driving traffic to this site? Online/Offline?
2. What is the schedule for that media?
3. What is the total exposure?
4. Are there any specific activities that would drive spikes in traffic? Superbowl Ad, etc.

So, that’s my list. After all of the questions are answered (which usually doesn’t happen all at once – it very often requires a bit of back and forth with the client and project managers), I create a tech brief or feature scope document based on the answers I from this questionnaire.

If the client doesn’t know the answers to some of the questions (“are you running linux or Microsoft?”), I do my best to find out who does. If the client can’t decide on something “do you need a content management system?”), I advise my project managers that we have to be given authority to make that decision for them. NO development will be done until the tech brief is done. Period.

I then get the client to SIGN the scope/brief so that they agree, in writing, to everything we’ve decided – and more importantly, what I expect from them, when I expect it, and what they can expect if I don’t get it on time – that way when they don’t deliver server access or copy/creative assets on time, there are no surprises when I tell them that we are not going to make their deadline.

The tech brief is written to protect both parties, the client and the service provider. When done properly, it helps manage client expectations, and protects you from being expected to deliver something that was not in the scope. Everyone knows what happens next, how much it will cost, and what the final product is supposed to do.

I’ll be updating this as new screw-ups happen and we (hopefully) continue to learn from them.

Leave your own in the comments, and feel free to download the (slightly longer) PDF version if it will help you do battle with middle management that doesn’t understand why you have to take so much time to plan your projects. 🙂