[consulting] consulting Digest, Vol 37, Issue 13

Sun Feb 22 21:21:53 UTC 2009

I may be able to relate to you Super Women :o) because I have been
both the developer for my own Drupal projects as well as have sought
Drupal helping hands on certain occasions.

If I have my business plan for my online infrastructure clearly
detailed and laid out, I won't have trouble aligning my business goals
to my online/IT goals or vice versa. What happens in most cases is
that since I am not sure myself about what I want, I end up screwing
up my own initiatives. This has happened within both my personal
projects as well as for clients.

My first advice, educate thyself and the clients about Drupal, its
base install, what you want to achieve in terms of business model or
as we nowadays say in the Drupal language Drupal Install Profiles,
E-Commerce or the CCK-Views custom content design strategies. Drupal
custom module development is whole different ball game and turns into
hardcore software development. I have seen many people to propose
Drupal solutions without a requirement analysis to a proper suggestion
of the functional aspects to the client.

Ten years ago I used to teach the basic principle of Interactive
Prototyping. 1. Information Design, 2. Interaction Design, 3.
Prototyping. The client has to be and must be involved in all three
stages and it used to be at prototyping that we used to take a sigh of
relief as we would end up with most of the things we required from the
client. Nowadays, agility is the cornerstone as many have already
replied to you. Agile design requires keeping the client in the loop
of everything related to ongoing improvements in both the design and
functionality because thats how things are today given the tools and
skills in the market as well as the business demand.

Secondly have a project communication system in place that can bug
clients, I know it feels its not a great idea to bug clients but as a
developer or solution architect, you have to send them tons of email
so that they can seriously respond to you and both in a timely manner.
You can always use third party intermediary websites like
www.odesk.com or www.rentacoder.com or even setup your own facility
using DotProjekt or Basecamp or Google Docs works fine for me.

As you have mentioned, its the multiple project syndrome in developers
that is really frustrating, well to tell you the truth, its because
clients try to play lets save what we can and end up screwing their
projects. You have to realize that every developer also has a living
to be made and some of the top seed Drupal developers are busy
achieving that but you can't place us all in the same basket. One way
to do this is to hire a developer on a fulltime basis remotely. You
will not have to spend overhead capital expenditures (reduced CAPEX)
and will just manage the Operational Costs (OPEX).

You can define in the terms of engagement that Skype shall always be
on. In my case I have a pda with Skype always on despite it staying on
on my laptop most of the time. Request a half week or weekly report
but create the structure yourself and just live simple tick and click
options through Google Docs for the developer so that you end with a
Progress Sheet and can monitor achievements, show stoppers and
disasters online.

Getting prior commitment from the developer should be your strategy.
If you hire a full time Drupal expert in the west, the charges will be
around 4-7k$ and half or even half of half of that in the South but
you have to keep in mind that within the remote sphere, Australia
sleeps way before the Asian South does.

my two cents though I may have drifted a bit from the subject at hand.
-- 

Regards.
--------------------------
Fouad Bajwa
@skBajwa
Answering all your technology questions
http://www.askbajwa.com
http://twitter.com/fouadbajwa

On Sun, Feb 22, 2009 at 10:39 PM,  <consulting-request at drupal.org> wrote:

> Today's Topics:
>
>   1. Re: Estimation-Blowout case-studies wanted
>      (superwoman at superwoman.org.au)
>   2. Re: Estimation-Blowout case-studies wanted (Yanto Daryanto)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 23 Feb 2009 00:30:15 +1100
> From: "superwoman at superwoman.org.au" <superwoman at superwoman.org.au>
> Subject: Re: [consulting] Estimation-Blowout case-studies wanted
> To: A list for Drupal consultants and Drupal service/hosting providers
>        <consulting at drupal.org>
> Cc: A list for Drupal consultants and Drupal service/hosting providers
>        <consulting at drupal.org>
> Message-ID: <7D210F7C-5107-4B99-85E0-439DDD441409 at superwoman.org.au>
> Content-Type: text/plain; charset="us-ascii"
>
> Ok now I've heard from you all. I'm quite educated in Drupal and I'm
> the client. Our biggest frustration with developers particularly those
> with multiple projects, is getting quick concise communication from
> I.T. People regards our projects and status I like deadlines met but
> also understand sometimes there are reasons why. Those reasons should
> not be other projects. I suggest if you commit to a project work
> diligently on it from the outset don't take on too many projects at
> once and most importantly clear communication as often as possible
> regards status issues and wins...
> I hope this helps as I am from the client side.....
>
> Sent from my iPhone
>
> On 22/02/2009, at 1:36 PM, Roshan Shah <roshan.shah at bpocanada.com>
> wrote:
>
>> Gwen,
>>
>> You have a very valid point.
>>
>> Getting client to respond quickly is one of the most challenging
>> thing. Secondly it is client's (limited) understanding of Drupal CMS
>> and thirdly is the scope creep and progressive elaborations that
>> happen during the project.
>>
>> Regardless of the contingencies put in place if any of the above is
>> not tightened up on contracts to have $$ value assigned, it can
>> really hurt you as a developer.
>>
>> Roshan
>> Gloscon Solutions Inc - http://www.gloscon.com
>> * Canada, India
>> Skype : bpocanada
>>
>> On Sun, Feb 22, 2009 at 12:21 AM, Gwennie Cakes <gwenniecakes at gmail.com
>> > wrote:
>> I totally agree with what Victor's saying, it's the whole agile/xp
>> way of looking at things. One of the other really useful things
>> about those methodologies is a quick daily check in. The idea is
>> that it should give everyone an idea of where everyone else is at so
>> the decision makers know if they need to adjust expectations,
>> requirements or whatever since, as Victor pointed out, change is
>> always part of the equation. To make it fast, the check in is
>> limited to 3 things at a high level: what I did yesterday, what I
>> plan to do today, any blockers I have. If folks need to discuss
>> points in greater detail, it's up to them to follow up offline. I've
>> had check ins with 20+ people that regularly took 10 or less
>> minutes. One other great thing about check ins is that they get the
>> client in the habit of talking to you for at least a few minutes
>> every day. I've had projects in the past where clients wouldn't
>> answer emails/calls for days and b/c I didn't have all the info I
>> needed, I made wrong decisions that further delayed things b/c they
>> had to be corrected. Much easier when you're on their radar for even
>> a small blip every day.
>>
>> gwen
>>
>>
>> On Sat, Feb 21, 2009 at 10:01 AM, Victor Kane <victorkane at gmail.com>
>> wrote:
>> These are all great ideas.
>>
>> The problem is that everyone is still clued into getting from A to
>> B, with change seen as the exception rather than the rule.
>>
>> Change is the way the client finds out what they want. The only way
>> that can help instead of hinder is if the client participates
>> directly in the work; and if the work is done in iterative,
>> incremental short bursts, or sprints, or phases.
>>
>> Change doesn't just mean "I want green instead of grey". It also is
>> the way people realize what it is they wanted in the first place, or
>> what they thought they meant.
>>
>> The rapid feedback of the short sprints can save everyone time, and
>> everyone gets better at it as time passes.
>>
>> Otherwise things get too mechanical and no-one gets what they want.
>>
>> Just my two cents.
>>
>>
>> Victor Kane
>> http://awebfactory.com.ar
>> http://projectflowandtracker.com (behind schedule :)
>>
>>
>> On Sat, Feb 21, 2009 at 3:36 PM, Gwennie Cakes
>> <gwenniecakes at gmail.com> wrote:
>> One strategy a friend has pursued with some success is to put a
>> client friendly hour cap on fixed rate work. Most clients are
>> willing to be fair (tho often not generous) about compensation, so
>> if you spend a little time explaining the issues involved in
>> estimating hours (new requirements coming up, guessing how much time
>> will be wasted by communications snafus, weird bugs in 3rd party
>> code, etc.), they're often cool with putting a max hourly cap on
>> work. Particularly if you mention you usually charge $x an hour for
>> hourly work and skew max hours in their favor, it feels like they're
>> getting a discount.
>>
>> For drupal specifically, someone I know puts a clause into their
>> contracts that says something like: "I'm going to use x, y and z
>> modules to meet a, b and c requirements to build your site faster.
>> Work estimated only includes installation, configuration and basic
>> themeing of these 3rd party modules. If I need to write extra custom
>> code b/c the module developer did something not exactly how you want
>> it, we'll have to negotiate for extra work."
>>
>> Finally, for estimating hours, most project managers I know *at
>> least* double developer estimates, sometimes going as high as 3x if
>> it's a large project with lots of moving parts. If you're playing
>> project manager to yourself, it can feel weird to do this, but it's
>> a smart thing to do since a lot of delays are client side (slow/bad
>> communication, changing requirements, delayed decision making, super
>> nitpicky, etc). Elvis' point about gauging your client is really
>> spot on when it comes to adjusting the multiplier.
>>
>> gwen
>>
>>
>> On Sat, Feb 21, 2009 at 8:50 AM, Elvis McNeely
>> <office at mcneelycorp.com> wrote:
>> Found to be clean,
>> 0X-Spam-Status: No
>> X-AntiAbuse: This header was added to track abuse, please include it
>> with any abuse report
>> X-AntiAbuse: Primary Hostname - server2.lafayetteweb.com
>> X-AntiAbuse: Original Domain - drupal.org
>> X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
>> X-AntiAbuse: Sender Address Domain - mcneelycorp.com
>>
>> For what it is worth... Last year at the DrupalCon Boston, a Drupal
>> shop
>> owner answered my "how do you estimate more accurately" question like
>> this; Review the specs, estimate in hours like you normally would,
>> then
>> multiply that by 1.7 (or 170%). I have used that model with some
>> success.
>>
>> I also try to weigh clients. Are they laid back, high maintenance,
>> know
>> what they want, a puppet for the board (who decides what goes or
>> stays)
>> etc. If any red flags come out of the initial consultation I make note
>> and change that 1.7 by some factor.
>>
>> It is not easy to have accurate estimates. If too many red flags
>> come up
>> early on, you always have the choice to walk away. Would you rather
>> slave under a "estimate blowout" and tarnish your reputation or know
>> you/staff are getting paid fairly and get more referrals?
>>
>> Nice conversation. I am interested in hearing more how Drupal
>> freelancers / shop owners handle this...
>>
>> ====================
>> Elvis McNeely
>> office: (765) 463-6221
>> skype me: elvis.mcneely
>> blog: http://elvisblogs.org
>> Web Developer / Freelancer / Drupal Specialist
>> Recent Work: http://elvisblogs.org/drupal-work
>> What is Drupal? http://drupal.org
>>
>> Brian Vuyk wrote:
>> > What you mention below is the main reason I tend to go over my
>> initial
>> > hourly projections - it's impossible to know the specific problems
>> you
>> > will face implementing a lot of non-core functionality until
>> you've done
>> > it!
>> >
>> > With my projects, I've taken to estimating the hours involved before
>> > hand on paper. Then I add up to 50% more hours, depending on the
>> scope
>> > and complexity of the project. This usually brings me fairly close
>> to
>> > the hours a project ends up working out to. Of course, this approach
>> > probably doesn't work for everyone; I think I have a bad habit of
>> > estimating low and requiring such a safety margin. On the (fairly
>> rare)
>> > occasion where I come in a ways under what I quoted on, I will
>> usually
>> > implement a few 'extra' features that may have been tossed around
>> with
>> > the client, but put aside for various reasons.
>> >
>> > As per Victor Cane's comments on specifications changes, my clients
>> > usually sign to a set of specifications prior to the project
>> beginning
>> > building. Any major specification changes are negotiated as they
>> come
>> > up. That is, I will give the client an estimate on the extra cost
>> and
>> > schedule impacts that these changes will bring.
>> >
>> > Brian
>> >
>> > Sam Cohen wrote:
>> >> To start, if a client wants any non-core functionality, there's the
>> >> issue of whether or not a module exists that can do this.  And if
>> >> there is,  how close will it get.
>> >>
>> >> It's often not possible or practical to do the research it would
>> take
>> >> to determine these things up front, so there's an enormous amount
>> of
>> >> guess work involved.
>> >>
>> >> Sam
>> >>
>> >>
>> >>
>> ---
>> ---------------------------------------------------------------------
>> >>
>> >> _______________________________________________
>> >> consulting mailing list
>> >> consulting at drupal.org
>> >> http://lists.drupal.org/mailman/listinfo/consulting
>> >>
>> >
>> > _______________________________________________
>> > consulting mailing list
>> > consulting at drupal.org
>> > http://lists.drupal.org/mailman/listinfo/consulting
>> >
>> >
>> >
>> ---
>> ---------------------------------------------------------------------
>> >
>> >
>> > No virus found in this incoming message.
>> > Checked by AVG - www.avg.com
>> > Version: 8.0.237 / Virus Database: 270.11.2/1964 - Release Date: 02/21/09 11
>> :05:00
>> >
>> _______________________________________________
>> consulting mailing list
>> consulting at drupal.org
>> http://lists.drupal.org/mailman/listinfo/consulting
>>
>>
>> _______________________________________________
>> consulting mailing list
>> consulting at drupal.org
>> http://lists.drupal.org/mailman/listinfo/consulting
>>
>>
>>
>> _______________________________________________
>> consulting mailing list
>> consulting at drupal.org
>> http://lists.drupal.org/mailman/listinfo/consulting
>>
>>
>>
>> _______________________________________________
>> consulting mailing list
>> consulting at drupal.org
>> http://lists.drupal.org/mailman/listinfo/consulting
>>
>>
>>
>>
>> --
>> --
>>
>> _______________________________________________
>> consulting mailing list
>> consulting at drupal.org
>> http://lists.drupal.org/mailman/listinfo/consulting
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://lists.drupal.org/pipermail/consulting/attachments/20090223/8be6df86/attachment-0001.htm
>
> ------------------------------
>
> Message: 2
> Date: Sun, 22 Feb 2009 23:31:04 +0700
> From: Yanto Daryanto <yanto at nyieunweb.com>
> Subject: Re: [consulting] Estimation-Blowout case-studies wanted
> To: "A list for Drupal consultants and Drupal service/hosting
>        providers"      <consulting at drupal.org>
> Message-ID:
>        <3e67a0480902220831o37f08bc1w5cb33c17d5232539 at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> 1. Client should guarantee to freelancer that they have right person to
> dedicate. Freelancer is different from employer, because they are living in
> the edge. Another projects is sometime back up from another failed project
> to make their live.Let say i'm a freelancer. I always thinking "Are they
> good client to dedicate?".
> 2. If you frustrated with freelancers, try to hired employer, then you can
> control every day and every works time.
> 3. You should careful to make a deadline, try to get some advice from
> developers, some client dont know about developing process, they usually
> knew only general process/work flow and it should be easy but not in the
> reality.
> 4. You should break up each requirement into small tasks then you can
> estimate work hours, some terms called it by "Ticket". Dont give ticket by
> generall, eg: "I want clone of yahoo.com", or "I want design looks good", or
> "header is wider". Those are better "Make home page have similar layout with
> yahoo.com, with header, left column, content, right column and footer with
> size xxxx respectively", or "make header smaller 10-20 pixels" and you can
> estimate how many minutes will be spent for this tasks.
> 5. Try to understand that software development always hard, You know how
> much years to develop drupal framework with thousand expert. So you must
> clear your requirement and limit scope of the requirement. try from simple
> thing first
> 6. I agree with clear communications, this is the most important thing
> 7. If you want to change some closed tasks, you should make new tasks for
> it. and you can estimate how many hours for it. also when bugs found.
> 8. Use project management tools, svn, git, ticket management and you can
> control each task and code per char
> 9. Try to understand capabilities of freelancer. Give trial work for few
> days or a week.
>
> I used "freelancers" than "developer" because your statement about
> "frustrated with developers particularly those with multiple projects..". If
> developer is employer, they should not admitted to take another projects
>
>
> Thanks
>
> On Sun, Feb 22, 2009 at 8:30 PM, superwoman at superwoman.org.au <
> superwoman at superwoman.org.au> wrote:
>
>> Ok now I've heard from you all. I'm quite educated in Drupal and I'm the
>> client. Our biggest frustration with developers particularly those with
>> multiple projects, is getting quick concise communication from I.T. People
>> regards our projects and status I like deadlines met but also understand
>> sometimes there are reasons why. Those reasons should not be other projects.
>> I suggest if you commit to a project work diligently on it from the outset
>> don't take on too many projects at once and most importantly clear
>> communication as often as possible regards status issues and wins...
>> I hope this helps as I am from the client side.....
>>
>> Sent from my iPhone
>>
>> On 22/02/2009, at 1:36 PM, Roshan Shah <roshan.shah at bpocanada.com> wrote:
>>
>> Gwen,
>>
>> You have a very valid point.
>>
>> Getting client to respond quickly is one of the most challenging thing.
>> Secondly it is client's (limited) understanding of Drupal CMS and thirdly is
>> the scope creep and progressive elaborations that happen during the project.
>>
>> Regardless of the contingencies put in place if any of the above is not
>> tightened up on contracts to have $$ value assigned, it can really hurt you
>> as a developer.
>>
>> Roshan
>> Gloscon Solutions Inc - <http://www.gloscon.com>http://www.gloscon.com
>> * Canada, India
>> Skype : bpocanada
>>
>> On Sun, Feb 22, 2009 at 12:21 AM, Gwennie Cakes < <gwenniecakes at gmail.com>
>> gwenniecakes at gmail.com> wrote:
>>
>>> I totally agree with what Victor's saying, it's the whole agile/xp way of
>>> looking at things. One of the other really useful things about those
>>> methodologies is a quick daily check in. The idea is that it should give
>>> everyone an idea of where everyone else is at so the decision makers know if
>>> they need to adjust expectations, requirements or whatever since, as Victor
>>> pointed out, change is always part of the equation. To make it fast, the
>>> check in is limited to 3 things at a high level: what I did yesterday, what
>>> I plan to do today, any blockers I have. If folks need to discuss points in
>>> greater detail, it's up to them to follow up offline. I've had check ins
>>> with 20+ people that regularly took 10 or less minutes. One other great
>>> thing about check ins is that they get the client in the habit of talking to
>>> you for at least a few minutes every day. I've had projects in the past
>>> where clients wouldn't answer emails/calls for days and b/c I didn't have
>>> all the info I needed, I made wrong decisions that further delayed things
>>> b/c they had to be corrected. Much easier when you're on their radar for
>>> even a small blip every day.
>>>
>>> gwen
>>>
>>>
>>> On Sat, Feb 21, 2009 at 10:01 AM, Victor Kane < <victorkane at gmail.com>
>>> victorkane at gmail.com> wrote:
>>>
>>>> These are all great ideas.
>>>>
>>>> The problem is that everyone is still clued into getting from A to B,
>>>> with change seen as the exception rather than the rule.
>>>>
>>>> Change is the way the client finds out what they want. The only way that
>>>> can help instead of hinder is if the client participates directly in the
>>>> work; and if the work is done in iterative, incremental short bursts, or
>>>> sprints, or phases.
>>>>
>>>> Change doesn't just mean "I want green instead of grey". It also is the
>>>> way people realize what it is they wanted in the first place, or what they
>>>> thought they meant.
>>>>
>>>> The rapid feedback of the short sprints can save everyone time, and
>>>> everyone gets better at it as time passes.
>>>>
>>>> Otherwise things get too mechanical and no-one gets what they want.
>>>>
>>>> Just my two cents.
>>>>
>>>> Victor Kane
>>>> <http://awebfactory.com.ar>http://awebfactory.com.ar
>>>>  <http://projectflowandtracker.com>http://projectflowandtracker.com(behind schedule :)
>>>>
>>>>
>>>> On Sat, Feb 21, 2009 at 3:36 PM, Gwennie Cakes <<gwenniecakes at gmail.com>
>>>> gwenniecakes at gmail.com> wrote:
>>>>
>>>>> One strategy a friend has pursued with some success is to put a client
>>>>> friendly hour cap on fixed rate work. Most clients are willing to be fair
>>>>> (tho often not generous) about compensation, so if you spend a little time
>>>>> explaining the issues involved in estimating hours (new requirements coming
>>>>> up, guessing how much time will be wasted by communications snafus, weird
>>>>> bugs in 3rd party code, etc.), they're often cool with putting a max hourly
>>>>> cap on work. Particularly if you mention you usually charge $x an hour for
>>>>> hourly work and skew max hours in their favor, it feels like they're getting
>>>>> a discount.
>>>>>
>>>>> For drupal specifically, someone I know puts a clause into their
>>>>> contracts that says something like: "I'm going to use x, y and z modules to
>>>>> meet a, b and c requirements to build your site faster. Work estimated only
>>>>> includes installation, configuration and basic themeing of these 3rd party
>>>>> modules. If I need to write extra custom code b/c the module developer did
>>>>> something not exactly how you want it, we'll have to negotiate for extra
>>>>> work."
>>>>>
>>>>> Finally, for estimating hours, most project managers I know *at least*
>>>>> double developer estimates, sometimes going as high as 3x if it's a large
>>>>> project with lots of moving parts. If you're playing project manager to
>>>>> yourself, it can feel weird to do this, but it's a smart thing to do since a
>>>>> lot of delays are client side (slow/bad communication, changing
>>>>> requirements, delayed decision making, super nitpicky, etc). Elvis' point
>>>>> about gauging your client is really spot on when it comes to adjusting the
>>>>> multiplier.
>>>>>
>>>>> gwen
>>>>>
>>>>>
>>>>> On Sat, Feb 21, 2009 at 8:50 AM, Elvis McNeely <<office at mcneelycorp.com>
>>>>> office at mcneelycorp.com> wrote:
>>>>>
>>>>>> Found to be clean,
>>>>>> 0X-Spam-Status: No
>>>>>> X-AntiAbuse: This header was added to track abuse, please include it
>>>>>> with any abuse report
>>>>>> X-AntiAbuse: Primary Hostname - server2.lafayette<http://server2.lafayetteweb.com>
>>>>>> web.com
>>>>>> X-AntiAbuse: Original Domain - drupal.org
>>>>>> X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
>>>>>> X-AntiAbuse: Sender Address Domain - mcneelycorp.com
>>>>>>
>>>>>> For what it is worth... Last year at the DrupalCon Boston, a Drupal
>>>>>> shop
>>>>>> owner answered my "how do you estimate more accurately" question like
>>>>>> this; Review the specs, estimate in hours like you normally would, then
>>>>>> multiply that by 1.7 (or 170%). I have used that model with some
>>>>>> success.
>>>>>>
>>>>>> I also try to weigh clients. Are they laid back, high maintenance, know
>>>>>> what they want, a puppet for the board (who decides what goes or stays)
>>>>>> etc. If any red flags come out of the initial consultation I make note
>>>>>> and change that 1.7 by some factor.
>>>>>>
>>>>>> It is not easy to have accurate estimates. If too many red flags come
>>>>>> up
>>>>>> early on, you always have the choice to walk away. Would you rather
>>>>>> slave under a "estimate blowout" and tarnish your reputation or know
>>>>>> you/staff are getting paid fairly and get more referrals?
>>>>>>
>>>>>> Nice conversation. I am interested in hearing more how Drupal
>>>>>> freelancers / shop owners handle this...
>>>>>>
>>>>>> ====================
>>>>>> Elvis McNeely
>>>>>> office: (765) 463-6221
>>>>>> skype me: elvis.mcneely
>>>>>> blog: <http://elvisblogs.org>http://elvisblogs.org
>>>>>> Web Developer / Freelancer / Drupal Specialist
>>>>>> Recent Work: <http://elvisblogs.org/drupal-work>
>>>>>> http://elvisblogs.org/drupal-work
>>>>>> What is Drupal? <http://drupal.org>http://drupal.org
>>>>>>
>>>>>> Brian Vuyk wrote:
>>>>>> > What you mention below is the main reason I tend to go over my
>>>>>> initial
>>>>>> > hourly projections - it's impossible to know the specific problems
>>>>>> you
>>>>>> > will face implementing a lot of non-core functionality until you've
>>>>>> done
>>>>>> > it!
>>>>>> >
>>>>>> > With my projects, I've taken to estimating the hours involved before
>>>>>> > hand on paper. Then I add up to 50% more hours, depending on the
>>>>>> scope
>>>>>> > and complexity of the project. This usually brings me fairly close to
>>>>>> > the hours a project ends up working out to. Of course, this approach
>>>>>> > probably doesn't work for everyone; I think I have a bad habit of
>>>>>> > estimating low and requiring such a safety margin. On the (fairly
>>>>>> rare)
>>>>>> > occasion where I come in a ways under what I quoted on, I will
>>>>>> usually
>>>>>> > implement a few 'extra' features that may have been tossed around
>>>>>> with
>>>>>> > the client, but put aside for various reasons.
>>>>>> >
>>>>>> > As per Victor Cane's comments on specifications changes, my clients
>>>>>> > usually sign to a set of specifications prior to the project
>>>>>> beginning
>>>>>> > building. Any major specification changes are negotiated as they come
>>>>>> > up. That is, I will give the client an estimate on the extra cost and
>>>>>> > schedule impacts that these changes will bring.
>>>>>> >
>>>>>> > Brian
>>>>>> >
>>>>>> > Sam Cohen wrote:
>>>>>> >> To start, if a client wants any non-core functionality, there's the
>>>>>> >> issue of whether or not a module exists that can do this.  And if
>>>>>> >> there is,  how close will it get.
>>>>>> >>
>>>>>> >> It's often not possible or practical to do the research it would
>>>>>> take
>>>>>> >> to determine these things up front, so there's an enormous amount of
>>>>>> >> guess work involved.
>>>>>> >>
>>>>>> >> Sam
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> ------------------------------------------------------------------------
>>>>>> >>
>>>>>> >> _______________________________________________
>>>>>> >> consulting mailing list
>>>>>> >> <consulting at drupal.org>consulting at drupal.org
>>>>>> >> <http://lists.drupal.org/mailman/listinfo/consulting>
>>>>>> http://lists.drupal.org/mailman/listinfo/consulting
>>>>>> >>
>>>>>> >
>>>>>> > _______________________________________________
>>>>>> > consulting mailing list
>>>>>> > <consulting at drupal.org>consulting at drupal.org
>>>>>> > <http://lists.drupal.org/mailman/listinfo/consulting>
>>>>>> http://lists.drupal.org/mailman/listinfo/consulting
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> ------------------------------------------------------------------------
>>>>>> >
>>>>>> >
>>>>>> > No virus found in this incoming message.
>>>>>> > Checked by AVG - <http://www.avg.com>www.avg.com
>>>>>> > Version: 8.0.237 / Virus Database: 270.11.2/1964 - Release Date:
>>>>>> 02/21/09 11:05:00
>>>>>> >
>>>>>> _______________________________________________
>>>>>> consulting mailing list
>>>>>>  <consulting at drupal.org>consulting at drupal.org
>>>>>>  <http://lists.drupal.org/mailman/listinfo/consulting>
>>>>>> http://lists.drupal.org/mailman/listinfo/consulting
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> consulting mailing list
>>>>>  <consulting at drupal.org>consulting at drupal.org
>>>>>  <http://lists.drupal.org/mailman/listinfo/consulting>
>>>>> http://lists.drupal.org/mailman/listinfo/consulting
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> consulting mailing list
>>>>  <consulting at drupal.org>consulting at drupal.org
>>>>  <http://lists.drupal.org/mailman/listinfo/consulting>
>>>> http://lists.drupal.org/mailman/listinfo/consulting
>>>>
>>>>
>>>
>>> _______________________________________________
>>> consulting mailing list
>>>  <consulting at drupal.org>consulting at drupal.org
>>>  <http://lists.drupal.org/mailman/listinfo/consulting>
>>> http://lists.drupal.org/mailman/listinfo/consulting
>>>
>>>
>>
>>
>> --
>> --
>>
>> _______________________________________________
>> consulting mailing list
>> consulting at drupal.org
>> http://lists.drupal.org/mailman/listinfo/consulting
>>
>>
>> _______________________________________________
>> consulting mailing list
>> consulting at drupal.org
>> http://lists.drupal.org/mailman/listinfo/consulting
>>
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://lists.drupal.org/pipermail/consulting/attachments/20090222/aa7a5eec/attachment.htm
>
> ------------------------------
>
> _______________________________________________
> consulting mailing list
> consulting at drupal.org
> http://lists.drupal.org/mailman/listinfo/consulting
>
>
> End of consulting Digest, Vol 37, Issue 13
> ******************************************
>