[consulting] Drupal-friendly Graphic Design (new subject)

Tue Mar 10 19:42:54 UTC 2009

Thank you everyone who weighed in on the importance of using a
Drupal-friendly graphic design. Perhaps we can further discuss how this
process works.

So far I detect one main idea coming through: advise the graphic designer on
what default "out of the box" implementations look like, possibly by
building a prototype first and then telling the graphic designer to use it
as an architectural outline.

Are there other methods you might suggest? Is it helpful to give a graphic
designer a list of readily available variables to play around with? Or to
present a choice of basic layout structures that are easy to implement in
Drupal?

Any additional ideas would be appreciated.

Thanks,
Eric

On Sun, Mar 1, 2009 at 6:43 PM, Ashraf Amayreh <mistknight at gmail.com> wrote:

> I guess I forgot to state the overall goal of the prototype I presented
> above with regards to time estimation. By conveying visual features to the
> client you eliminate the possibility of miscommunication and missing
> requirements (the prototype essentially freezes client requirements in a
> visual way). You also restrict a designer to a design that is Drupal
> friendly (he needs to stick to the architecture/prototype).
>
> This will ultimately help in creating a more accurate project estimate,
> would clarify the site flow, and prevent the case where a design handed down
> from the client is a total Drupal design nightmare. Or at least that's the
> theory :)
>
> --
> Ashraf Amayreh
> http://aamayreh.org
>
>
> On Mon, Mar 2, 2009 at 3:38 AM, Alex Urevick-Ackelsberg <Alex at zivtech.com>wrote:
>
>> Here's a question: are developers able to share their rates amongst each
>> other? I'm not a lawyer, so don't take my word for it, but I'd be careful
>> about posting your rates on the Consultant list, as someone might consider
>> it an attempt at "price fixing"/collusion.
>>
>> I think it's a gray area, and I don't know if anyone out there really
>> cares about whether Drupal shops publicly share their rates, but I thought
>> I'd put that out there.
>>
>> --
>> Alex Urevick-Ackelsberg
>> ZivTech, LLC
>> http://zivtech.com
>> alex at zivtech.com
>> office: (267) 940-7737
>> cell: (215) 866-8956
>> skype: zivtech
>> aim: zivtech
>>
>>
>> On Sun, Mar 1, 2009 at 8:07 PM, Alex Urevick-Ackelsberg <Alex at zivtech.com
>> > wrote:
>>
>>> Wow! Thank you so much for this Henry!
>>>
>>> Would you be willing to do a BoF at DrupalCon (assuming you'll be
>>> there) to go over this?
>>>
>>> Also- what would be the best way for us to contribute to this effort?
>>> This something we struggle with as well, and your calculations seem
>>> pretty spot on for me.
>>>
>>> Thanks again, this really is a huge help!
>>>
>>> --
>>> Alex Urevick-Ackelsberg
>>> ZivTech, LLC
>>> http://zivtech.com
>>> alex at zivtech.com
>>> office: (267) 940-7737
>>> cell: (215) 866-8956
>>> skype: zivtech
>>> aim: zivtech
>>>
>>>
>>>
>>> On Sun, Mar 1, 2009 at 4:53 PM, Henry Poole <poole at civicactions.com>
>>> wrote:
>>> > A number of folks at CivicActions have been watching this conversation
>>> with
>>> > great interest. We've had similar challenges over the last couple of
>>> years,
>>> > and several months ago decided to create a tool to assist with
>>> estimating.
>>> > We ended up with a OpenOffice spreadsheet called
>>> > ca_template_estimating_worksheet. I posted it to the list here last
>>> week,
>>> > but it was rejected due to it's size. If you would like to check it
>>> out,
>>> > please find it posted at our website:
>>> > http://civicactions.com/estimating-worksheet
>>> >
>>> > Owen Barton, a partner at CivicActions and our Engineering Group
>>> Manager is
>>> > the maintainer of the tool. Last Friday he released version 1.1 and we
>>> > thought it might be of use to other Drupal consultants so we're
>>> publicly
>>> > releasing it for use under the Creative Commons Attribution Share Alike
>>> 3.0
>>> > license. You are free to use under the terms of this license. In the
>>> spirit
>>> > of the community in which we work, we would also appreciate that you
>>> share
>>> > any improvements with the rest of the community (back on this list
>>> would be
>>> > great).
>>> >
>>> > The file (posted at http://civicactions.com/estimating-worksheet)
>>> contains
>>> > five worksheets:
>>> >
>>> > 1. Intro contains important notes on the tool.
>>> > 2. Line-Item Estimate is for estimates of individual work items based
>>> on the
>>> > provided RFP/documentation. The totals from this are used in the other
>>> > sheets.
>>> > 3. RFP Estimate calculates final hour and cost estimates and includes
>>> all
>>> > functionality that is reasonable to implement from the RFP or
>>> documentation
>>> > provided.
>>> > 4. Recommended Estimate calculates final hour and cost estimates and
>>> makes
>>> > allowances to avoid major custom work and focus on high-value
>>> out-of-the-box
>>> > functionality. This is generally only used when the estimate for the
>>> RFP
>>> > exceeds the available budget. Please note that this sheet is disabled
>>> by
>>> > default - to enable use the switch on the sheet.
>>> > 5. Client Summary is a friendly summary of the information we normally
>>> > include with our proposals. The values from this sheet can be copy and
>>> > pasted from this sheet into a new spreadsheet file or into the proposal
>>> > document.
>>> >
>>> > Overview of Features:
>>> > ● Takes into account the certainty of the line item estimates (allowing
>>> for
>>> > vague RFPs, technical risks and areas that need research) to produce
>>> low and
>>> > high estimates, in addition to the 'normal' estimate that give an idea
>>> of
>>> > the expected range of variability.
>>> > ● Allows us to recommend reduced, simplified or alternative
>>> functionality
>>> > than what is requested (especially useful for clients with dreams
>>> bigger
>>> > than their pockets).
>>> > ● Calculates cost estimates based on actual role rates, rather than
>>> blended
>>> > rates.
>>> >
>>> > Types of estimates rolled into the total:
>>> > ● Line-item estimates are the traditional estimates that we have done.
>>> > Typically we would only do engineering line-item estimates at the
>>> proposal
>>> > stage - the other roles would be valuable however if we re-estimate
>>> post-IA
>>> > or post-strategy, where we have more information and need specific
>>> > information for budgeting and scheduling.
>>> > ● Duration estimates account for the fact that it takes a certain
>>> amount of
>>> > our time just to keep a project rolling.
>>> > ● Proportional estimates allows us to base an estimate on a proportion
>>> of
>>> > some other estimate, which is a useful way to estimate some of the QA
>>> and PM
>>> > work.
>>> > ● Manual estimates are a way to include a single aggregate estimate
>>> into the
>>> > totals - for example creative estimates sometimes use this.
>>> >
>>> > Not directly related to the spreadsheet, but other things to bear in
>>> mind
>>> > when estimating:
>>> >
>>> > ● Things always take longer than you think, be generous (but not
>>> silly!)
>>> > with your estimates. Getting this balance right is a fine art and takes
>>> time
>>> > to learn.
>>> > ● Make sure you think about, and state each assumption you make when
>>> > estimating.
>>> > ● Write any assumptions and notes in client friendly language - these
>>> notes
>>> > will often be included in the proposal.
>>> > ● If any RFP line item is looking too big, or actually is several
>>> things
>>> > rolled into one, split the line item into multiple work items.
>>> > ● Estimate each area of work (engineering, theming, configuration,
>>> > communication) separately, and make sure you include adequate time for
>>> > communication, both with the client to clarify the requirements, and
>>> also
>>> > internal communication between team members.
>>> > ● If the work includes new, untested code, e.g., writing a new module
>>> or
>>> > including a (non-standard) contrib module, add time in the estimate for
>>> unit
>>> > testing which could include the writing of simpletests and flag this to
>>> the
>>> > QA team as a place that will require additional QA.
>>> > ● You personally might be able to get a task done very fast, but others
>>> may
>>> > end up doing that work and may be slower - make sure your estimates
>>> allow
>>> > for this.
>>> > ● Vary the amount or research with the size of the line item - if you
>>> are
>>> > not sure about something, but it would only take 5 hours to build from
>>> > scratch, just put 5 hours - if you need to integrate with some 3rd
>>> party
>>> > system, and it might be a weeks work make sure that you understand the
>>> > requirements very well (ask the client questions to clarify where
>>> needed)
>>> > and research things fully.
>>> > ● Never (ever!) estimate 'to' a budget - your estimates for each line
>>> item
>>> > should disregard any information we have about the available budget.
>>> Instead
>>> > think purely in terms of how long it will take to get the job done. If
>>> the
>>> > hours exceed the budget we will discuss a reduced feature set (at least
>>> > initially) with the client. If the overall costs look like they will
>>> > massively exceed the budget then ask the client to prioritize first and
>>> > estimate a subset of the items.
>>> >
>>> > We maintain a list of suggested improvements for the tool, and are
>>> happy to
>>> > release future versions to anyone interested.
>>> >
>>> > Cheers.
>>> >>
>>> >> On Fri, Feb 20, 2009 at 6:34 PM, John Saward <john at also.com.au>
>>> wrote:
>>> >>>
>>> >>> I'm currently very interested in people's experiences with
>>> >>> 'estimation-blowout'.
>>> >>>
>>> >>> In my experience, and discussions with Project Managers, Developers
>>> >>> and Clients I find that quite often the number of hours to actually
>>> >>> complete a Drupal project or task, is considerably more than the
>>> >>> number of hours estimated beforehand. This creates problems
>>> >>> (budgetary and otherwise) and stress and even resentments to all
>>> >>> involved whether the work is being performed on a
>>> >>> fixed-price-quotation, estimated or actual-hours basis.
>>> >>>
>>> >>> I note the comment from the team who recently updated drupal.orgfrom
>>> >>> 5 to 6, "So while we crafted a fine plan for the upgrade, it took a
>>> >>> few more hours then originally planned."
>>> http://drupal.org/node/376454.
>>> >>>
>>> >>> I'm understanding that the preparation and planning for the upgrade
>>> >>> was a mammoth task, when I read the report of the upgrade sprint, at
>>> >>> http://drupal.org/node/366562. Those at the sprint, and other
>>> >>> contributors, worked hard doing all that was humanly possible to
>>> >>> prepare and plan for the upgrade so that least downtime as possible
>>> >>> would be entailed.  One outcome of the sprint would have been an
>>> >>> estimation of how many hours would be required for the final push,
>>> >>> the working time that would necessarily entail site downtime. And now
>>> >>> I see that the actual upgrade was more intricate and time-consuming
>>> >>> than that prediction.
>>> >>>
>>> >>> My thinking is that these guys are some of the most experienced
>>> >>> Drupal engineers around; and most familiar with the entire
>>> drupal.org
>>> >>> infrastructure. If they are unable to predict the hours beforehand,
>>> >>> even after going into 'fine planning' .... well.... who could have?
>>> >>>
>>> >>> What does it take to accurately estimate a significant Drupal
>>> >>> project? Experience obviously, but it seems that is not always enough
>>> >>> in itself. Are there just always too many unknowns, too many
>>> >>> variables, too many 'what ifs' to be overlooked, in any
>>> >>> more-than-basic Drupal work?  Is accurate estimation for anything
>>> >>> other than highly-repetitive tasks.... verging on the impossible?
>>> >>>
>>> >>> I'm interested in hearing views and experiences about this.
>>> >>>
>>> >>> And also I'm interested to know if the upgrade team has a record of
>>> >>> hours predicted against actual hours taken, for the upgrade.
>>> >>>
>>> >>> John
>>> >>>
>>> >>> ==============
>>> >>> John Saward
>>> >>> www.drupal.com.au
>>> >>> 03 5968 1541
>>> >>> ==============
>>> >>>
>>> >>> _______________________________________________
>>> >>> consulting mailing list
>>> >>> consulting at drupal.org
>>> >>> http://lists.drupal.org/mailman/listinfo/consulting
>>> >>
>>> >>
>>> >
>>> >
>>> > --
>>> > Henry Poole, Partner, CivicActions LLC
>>> > Co-Founder, Virtual Artists
>>> > Board Member, Free Software Foundation
>>> > Blog: http://www.civicactions.com/blog/henripoole/
>>> >
>>> > Cell: +1 510 684 3180
>>> >
>>> > **************************************************************
>>> >
>>> > Henry: Now in Berkeley
>>> >
>>> > **************************************************************
>>> >
>>> > _______________________________________________
>>> > 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
>
>

-- 
Eric Broder
Director, Green Oak Web Design
greenoakwebdesign.com
510.410.8158
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/consulting/attachments/20090310/e53eca32/attachment-0001.htm 