Spec'ing Drupal Jobs

There's a support group meeting tonight at CSI. :-P

Hopefully this'll give the new folk something to think about. While trial-by-fire gives great scars and war stories, it's not the best way to enter the consultancy world...

I'm with Boris on this one at an abstract level. There are always limits about what's up for discussion, and when too many things are up for discussion, then the decisions that do need to be made will be made poorly. As a consultant, you have the responsibility to decide some things. Do you ask them whether they want a secure website or one that will be hacked? No. Do you ask them whether they want a site that will be impossible to maintain? No.

You should be clear about when you're not giving them choices, it's not about hiding them. And obviously, there are many choices they should make. They're paying you to know the difference.

Hi Guys,

While it warms my heart to see all this participation about a boring topic like spec'ing a Drupal job, I fear that our thread may be spinning off on a bit of a tangent about the pros and cons of Conservatism vs Liberalism. At the end of the day, they are philosophies of doing business/politics. My personal choice is the path of common sensism. :) In all seriousness, the client environment speaks volumes about your choices, which is where the common sense comes in.

In many instances, big clients will have full blown Unix departments. Many of the people in these Unix departments will smile at you, when you finally get around to them, as if you're some kind of Saint come to save them from their corporate pain. Universities often fall into this category to name just one example. In this case, all you need to do is ask: "what's your default Unix web server config?" Usually, all you'll have to do next is ask, can I have a sudo account please. They'll say: "Yeah man, on dev." The spec is now defined as: Internal Unix department is responsible for Dev environment. All you have to do is validate that it meets Drupal requirements. It's not quite that simple, but you get the general idea. When you're spec'ing the host piece it's largely about common sense.

What's common sense to us veterans is a foreign language to our new Consulting brothers and sisters. This is why the blog. It's up to you guys to share how you deal with key items that ultimately make up a trustworthy Drupal Spec. This way new Consultants can confidently say whether or not it's good or run for the hills.

Do me and the new kids the kindness of going back and commenting, ideally on the blog so that we can contain the rant in one location. The kind of comments I'm looking for are: "Hey Rob, you forgot to put in a section on migrating old sites, functionality, files, and databases into Drupal. That's a critical element you left out that can sting the new guys. Put that in there for goodness sakes." Another example would be: "For those clients who haven't got a clue about hosting, you need to present them with the most responsible solution, at low, medium, and high quality price ranges."

Who knows, if we can build a mutually agreed upon mature spec'ing document, we might even help ourselves. I mean, if we're comparing our jobs to romantic careers like Doctors, even Pilots have check lists. They get lots of dates I'm told. :)

PS Whether you involve Aliens in your brain surgery is less important than whether or not you live to tell about it. I suspect brain surgeons have heard some crazier things than Aliens needing to be involved in treatment plans. We Drupal consultants have heard some pretty crazy things too. I remember a client asking me on a Wednesday for a fully deployed e commerce streaming video solution by that Friday for the thousands of tapes in his library of video. Does this mean I sent him to another Drupal Doctor. I wanted to, but I didn't. I gave him a one page synopsis of his 3 options with approximate costs and time to complete. He decided the price tag was too high and I never heard another thing about it. I suspect this is how Brain Surgeons deal with the lucid family members. Here's your options....

My path would be Pastafarianism...

The thought that came from this was to what degree could someone new really learn from guidelines such as you have written. Maybe you're a bit more optimistic than I am. I see people making the same mistakes enough that I wonder if you have to make those mistakes.

Pain is the best teacher... mom told you not to touch the hot stove, but you just have to find out yourself. If you were going to try to communicate these lessons, I'd say: "start with the pain". Robert, your little anecdote of the problem (ie. client with unrealistic expectations) and your response would be far more instructive than merely listing what you should do.

I'd suggest that if you write more, put it in a storytelling format... the problem faced, mistakes made and lessons learned.

It would be nice to turn on a module that would allow specified folk to wiki their way through the development of the requirements, the FRD, the deliverables, etc. (Or use file posting and replacement) These documents are never done in a vacuum of a single persons thoughts. So while zooming down the checklist...perhaps some help gathering the needed information

And don't undervalue risk assessment and management strategies, hummm another great collaboration opportunity. There are risks to completing any project on time and in budget, failing to acknowledge and manage those risks potentially fatal. And the risks are present whether you are Agile or Waterfall.

What about quality assurance? How will you control the source? How will it be tested and verified to ensure it meets the customer requirements?

What about handling scope changes? Especially if you are using a waterfall method, the customer will eventually see something that is flashier or cooler that what was agreed to in the Design and FRD. A good project plan should recognize this is coming and plan for handling it, or make the customer aware that scope changes willnot be addressed.