This is the first part of a set of discussions which tries to document the best practices in the management of a successful drupal project from the qualification phase untill the successful signoff and delivery.
The overview thread can be found here - http://groups.drupal.org/node/9483
With the big demand all over the world for skilled drupal talent to deliver drupal based sites the question rises... How and when to say no to projects?
We all know of the client that want's a crazy array of features for a very small amount of money.
What other means do we have to asses if to enter a project?
Can this be measured - or is this only based on a gut feeling?
What are the alarm signs that immediately turn you off a project.
Remember this is a discussion this is the place to write stories and accumulated lessons and to see if these are general to the whole community.
By the way - I believe this stage is a great place to introduce yourself to the greater community and with this visibility new connections and networking emerge, the network of small (and larger) consulting companies may be your next source of quality projects.
Lior
Comments
Thanks Lior!
Thanks for starting this conversation, as it is something that I believe we all struggle with.
In my opinion, vetting prospective clients is more of an art than a science. The first thing that I always look for is the ability to clearly define what it is that they are looking for. As easy as this might seem, there are far more people who "know" what they want and can not say it (or than by saying it's not what they have or what you've thus far delivered) than vis versa. So, my first step is always to work with the prospective client to get clearly defined spec sheets (which are enforced via contracts) with prices attached to each part of the site build. Clients who want to start right away without this kind of agreement in place are common, but should be (imo) avoided, because regardless of how reasonable they may seem at first, their demands will almost certainly grow as the project proceeds.
The second step that I usually go through with a client is trying to get them to understand the unique challenges that a CMS in general, and Drupal in particular, present for a project. I always tell clients that "the devil is in the details", and thus I always try to create a fairly large range of potential costs for the site. If a client balks at this and wants am exact figure I either give them the highest number, or walk away from the project.
Along the same lines, I always try to gauge how working with the client would go. Now, there are definitely people who can act as sweet as sugar at first but who turn into real PITAs as soon as a project commences, but usually I find that I can tell from the get go how a person will behave when you get into the thick of it. But while this is definitely more to the art part of things, you can easily bring it over to the science side by using well thought out and meticulously detailed contracts. As the saying goes: better fences make better neighbors.
One thing I espescially struggle with when dealing with perspective clients is saying 'No!', because I see myself not only as someone selling Drupal services, but as an "evangelist" selling Drupal itself and the Drupal way of doing things. So, every time a prospective client asks "Can Drupal do X?" I find myself saying "of course!" before they even get to X (usually I'm right, but the questions is always: how long does it take/at what cost?).
Anyway, thanks again for starting this conversation. I'm very interested to see where it goes.
Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology
Self goals
In soccer there is a scenario in which you inflict self damage by accidentally shooting a goal in to your own teams net.
I feel a lot like in the balance between the "get the project done" angel on one shoulder and the "you should really use the asset module for this and oooooh ooooh ooooh panels2 has just come out and would perfectly fit" devil on the other shoulder.
I can totally connect to the conflicting forces of running a drupal shop and evangelizing drupal and it's modules sometimes.
This has happened to me several times in the past where either a module didn't have enough themeing flexability or simply plainly did not work.
Boris preached a "create your authorised module list" and define a process to authorise new module to qualify for that list.
I'll open that as a new thread....
Thanks for sharing the insights - I too am interested in this converstation and am inviting all of the drupalshop owners to pitch in an d share their experiences and recipies...best regards
Lior
Linnovate - Community Infrastructure Care
Drupal Services in Israel
http://www.linnovate.net
Linnovate - Community Infrastructure Care
Drupal Services in Israel
http://www.linnovate.net