Spec'ing a Drupal site is as much or more of an art than a science. Talk to any web design veteran and you'll have a gay old time trading stories about the world of web design. At the end of it, you'll be entertained, smiling, and very confused. Not to worry though. Once you've completed a few sites, and made all the mistakes, it's easy. Use common sense, and give the client more than what they want at a reasonable price with zero headache is the key, just like every other business success formula. This is all accomplished through a great initial specification.
Before we dive into the spreadsheet, the 1,2,3's and the A,B,C's of it all, we need to review the common sense element of spec'ing a Drupal site. Much of this comes from being able to read your environment. As an example to illustrate the point, lets suppose your mission is to deliver a Drupal site to a 20 person Tool and Die Shop owned by two cantankerous anti-technology old men. You ask them why they want a website. They say: “my son-in-law thinks we have to get on the web to grow the business and spend crazy amounts of money like $10,000”, and then they look at one another and chuckle. Now you know a good part of where the decision makers thinking is at. This is key. You know the driving force behind the site is not the people handling the purse strings. You also know that your budget better not be big or the project will be a bust. You also know that it will be as much of a training job for you as a development job. All of these factors need to guide your next steps in eliciting the specifications of the job and they're all a condition of common sense.
Now that you've learned that the “son-in-law” will be the key client contact on the job, you can get down to business asking him the key questions. What's your actual budget? Why are you doing this project? To accomplish what goals? You realize that half the cost of the project will be required up-front? They may want you to come up with an e commerce solution that stores peoples credit cards exposing you to limitless financial liability, if anyone ever hacks your host. If at the end of this candid discussion, you feel that you'll be bearing all the risk associated with this job and the compensation is nowhere near what it should bet, then you should politely decline the offer. If, however, you're still excited about the possibility of completing another successful realistic Drupal site, then carry on to the actual site specifications phase.
Will the Drupal solution live on your site, a shared host, dedicated host, owned controlled and secured by the client or you? And what flavour will the OS be: Linux or Windows? This is a key question. You need to know the answer to this in order to understand your working environment. Ideally you have a dedicated host controlled and secured by you as your production environment, assuming the security can be relied on. This will give you complete freedoms to use efficient Drupal development and sys admin tools such as Drush. This part of the job must be signed off by whoever is developing and administering the client site as a reasonable workable production environment, be it your internal employees or a third party off-shore development firm. If the client has no preference, as many won't, then you choose what works best for everyone at a price that fits the job. If you need to know more of the technical requirements of Drupal hosting, then go here.
Note: If you don't include your development lead, and systems administrator on this discussion, then don't blame them if the project goes bad. When the project is moved from your development server to the client host and it doesn't work due to PHP version conflict issues, your client may want their money back. This happens all the time. It'll be your fault.
Design requirements (Specifically the look and feel or Drupal theme):
Some clients will tell you that they don't care what their website looks like. This is a lie. They do care: a lot! What they're saying is that they just don't want to spend a lot of money on this part of the job. They don't want to waste any of their time on this part of the job. They will expect that you get this part done well, very very well. In fact, they may have in-house graphics designers who insist you make a custom Drupal theme that matches their wire frames down to the pixel, hexadecimal color, and gradient. Don't dismiss this part of the project without getting written confirmation that the client has chosen the default garland theme.
What I do in circumstances like this is take some time to find pre-made Drupal templates. This can be easily discovered by Google searching the top players in the clients industry. Most industries have websites that follow similar design characteristics: layout, color, regions, social network feeds, and much more. Once you've identified a pattern, then you can find a Drupal theme that puts your clients look and feel at the top of this industry with little effort. If no obvious solution jumps out at you, go with what you know is a great look and feel for their respective business. Present them 3 options and have them sign off on it. Most clients appreciate this decisive and confident approach.
If you're dealing with a large organization wanting a brand new theme, starting with wire-frame layouts, then you'll need to get granular in this part of the process. You'll need to know each theme variation with screen shots and wire frames with Information architecture details. You'll need to know color schemes, logos, menu details, content display parameters, regions, cck types, blocks, views, image exact dimensions: everything about the look and feel itemized in a spreadsheet. You may find that the client expects all of these website design services as a part of the process, needing to sign-off along the way. These details all have to be worked as a part of the specification process.
Keep in mind that the theme can be the most time consuming part of any project. This is because it's the tangible deliverable component of all your hard work. Take pride in it and do your homework with respect to the theme before you enter into any form of contract with anyone. After all, it's your good Consulting name on the theme as much or more than the name of your client.
The Drupal industry continues to grow because of how great Drupal is, how cost effective it is, and on and on. As a result, Drupal knowledge is growing everywhere. Many of the customers you work with will have sourced your specialty Drupal consulting services knowing a great deal about the benefits of Drupal. At least 50% of my customers fall into this category. Why I stress this as a part of the functionality specifications is that it presents a great deal of complexity. A little knowledge is a dangerous thing where web design is concerned because nobody but Drupal developers know how long things take or cost.
Let's suppose that a client has fallen in love with the Kaltura module and must have it, also using the third party Kaltura video services. This ties your hands as a solution provider a great deal with respect to the video functionality choices. In fact, your choices are entirely made for you. Use the Kaltura service, it's user interface, player, view variables, and admin interface is the video specification. Anything the client wants outside of what's available through Kaltura, will ultimately need to be designed either in conjuntion with Kaltura, or around Kaltura. This means you are now completely reliant on Kaltura for the video portion of your site.
Why is this important is because your client may not have tested the reliability of the Kaltura hosts. Nor may they have tested the response time of the Kaltura services once a disaster occurs. Is it one hour to recover the solution or 2 days? Your client may not realize that all video content now is controlled by the Kaltura servers. What if the Kaltura module is discontinued? What if Kaltura is sold for a billion dollars to Cisco then discontinued? Your client may not comprehend the consequences of this decision. I find they usually don't understand the consequences of their pre-made specifications.
It's your responsibility as a Drupal consultant to make your client aware of these decisions. You need to be strong in choosing the solutions that you know will benefit your client in achieving their goals. This will likely require some educating your client, potentially some arguing, and maybe even some hard-ball negotiating. This is the time to do it though at the beginning of your project. Flush out all critical functionality requirements at the beginning of the job.
Note: Many of your clients will not care at all about the contributed modules you use or don't use. Treat these clients well and choose wisely. Always consider using profiles to jump start your development environment. That's what they're there for.
Client Processes (The internal housekeeping part of qualifying and specifying whether the job is worth your while):
What I mean by client process is the way your clients assess your work to finally make payment. This is a factor of the way their IT department approves your code to give sign-off to the business people to make payment for your work. This is a factor of the way the clients graphics designers approve that your design matches theirs to get you paid for your work. This is a factor of the way that the Finance department validates your invoice against approved and budgeted work, and on and on and on. While you wouldn't think this would be something you have to think about as a new consultant, it is. In fact, the clients process of validating your work, is a very important, almost never discussed part of the job.
You need to spec out all these processes as an internal part of taking on new jobs. This is why a lot of designers prefer to work with small local clients. You have more control over negotiating these processes upfront as a part of taking on the job. There is less red tape and more likelihood that a chance awkward meeting in the supermarket will get you paid.
Bigger clients will have more fixed processes and greater layers of negotiation to make sure they have the least possible exposure to risk, and the greatest chance of getting you to foot the bill. After all, big business is all about making money. If you're going to play the game, understand the rules of engagement as a part of internally spec'ing out whether or not the job is worth your time.
You'll always find that there is more work involved than you first thought when you start asking these questions. You'll always find that there is significantly more administrative overhead. You'll find the communications part of the job is significantly greater than you could imagine. The processes involved in completing the job will directly affect your costs and you have to consider them.
Who will add the content on this site once it's done. Many organizations will assume that including images and text are a part of the whole website consulting offering. I have never offered it, but half my clients make this assumption. Most of us Drupal consultants are not qualified to write marketing copy for industries we know nothing about. This can be a major problem believe it or not, with respect to being able to satisfy a clients requirements. If they expected it and you didn't ask about it, they'll get a bad taste in their mouths about your degree of professionalism and the project will take a very negative turn. I've seen it. Specify who'll be responsible for content, how many roles are needed, if work-flow checks and balances are required, and how much training they'll need.
Search Engine Optimization and on-line markeing through social media:
Whether it comes up or not in the initial client planning meetings, search engine optimization and on-line marketing will always be a part of every project. Lucky for us, Drupal is exceptional is these areas. If you don't know why, learn. The SEO checklist module is a great place to start. Educate your client about it, so that it can be a part of their learning curve. At the end of the day, your client will expect to see tangible results by way of actual visits. Most will expect to be able to correlate dollars spent on web marketing to sales closed. Opening this topic as a part of the initial specifications of a job is critical for long-term continued client satisfaction.
Who will upgrade the Drupal site when security patches are released? This is another key question in whether or not you'll need to maintain an on-going relationship with the client. This will factor into their costs and yours. While it's easy to omit, it's a responsibility of Drupal designers to let clients know that there site will require upkeep to prevent the bad guys from doing silly things. Include this item in your specifications so that it doesn't come as a surprise later down the line.
Depending upon the technical abilities of each and every client contact touching the Drupal site, customer support can be a major expense. They'll assume that it's your responsibility to help them with Google Maps, FTP, many many things. I have spent weeks on servicing customers on non-development non-drupal related items alone to ensure overall client satisfaction. Some people don't like the default Drupal User interface. They complain about it a lot. You can change it to suit them to a degree, but regardless, customer support will take a great deal of your time. Specify a reasonable solution, and cost for this with your client upfront. You'll be glad you did.
Spec'ing a job is much more than creating a boiler plate for inexperienced salespeople in the world of Drupal consulting. It requires your direct involvement and an eye for detail in the areas of hosting, design, functionality, your clients way of doing business, content, Search engine optimization, maintenance, and customer support. The fun part is that this is just step one in coming up with a viable project. Step two is negotiating costs and terms for actually doing the job, while continuing to mainting the clients motivation to spend money. Step 3 is getting your internal production rate to match your time expectations, while continuing to balance everything else on your plate. How can you not love consulting Drupal in the corporate world, knowing all this? It makes sharing stories at lunches with compadres at DrupalCon events a lot of fun, once you break the ice.