List Info

Thread: Re: Pricing the Design Process




Re: Pricing the Design Process
user name
2007-02-12 14:07:29
jamie foggon:

If you can convince clients to pay you per hour, that's zero
risk
isn't it?

Ziya:

No, it isn't. Certainly not for the client or the project.

By-the-hour has a lot of shortcomings, a very short sampling
of which would
include:

+   It gives every incentive to the biller to pad his time
and maximize his
revenue at the expense of the client.


I was talking purely from the vendors perspective. Of course
there is
risk for the client - which is what I meant with my
reference to
getting clients to understand what agile development really
means -
and accepting the risk of scope on the promise of higher
quality.

You can still give a best guess estimate for the project as
a whole,
which for example, might be based on 4 iterations of 4
resources for 4
weeks. The reason you need trust on the part of the client
is because
you don't commit to x hundred features based on a vastly
detailed
proposal. Agile accepts that projects usually need to adapt
as they
progress, rather than predict exactly what the end result
will be.

I probably wasn't clear enough about what I mean't by hourly
billing.
With agile time-boxing it's not totally open ended - there
would
usually be an overall budget. And of course if the vendor
does not
deliver an acceptable product at the end of x iterations
then the
client will either demand a change in billing approach or a
change in
vendor 

Ziya:
+   It focuses the mind of the biller on deliverables,
instead of optimal
solutions or alternatives.
+   It practically eliminates any latitude for risks,
mistakes, experiments
and learning...

With agile it's the opposite. It's very light on
deliverables, the
focus switching to building a usable product at the end of
each
iteration. It's very user-centred in its approach as you can
build
user testing cycles into each iteration to feed into
requirements for
the next.

Probably a subject for a separate thread (if there hasn't
already been
one) is how the design process fits into the agile
methodology - which
has some big challenges. I'd be interested to hear other
people's
experiences with this.


-- 
Jamie Foggon
------------
IA Summit 2007:  Enriching IA
Rich Information, Rich Interaction, Rich Relationships
March 22-26, 2007, Las Vegas, NV
www.iasummit.org
-----
When replying, please *trim your post* as much as possible.
*Plain text, please; NO Attachments

Searchable Archive at http://www.in
fo-arch.org/lists/sigia-l/




________________________________________
Sigia-l mailing list -- post to: Sigia-lasis.org
Changes to subscription: http://
mail.asis.org/mailman/listinfo/sigia-l

Re: Pricing the Design Process
country flaguser name
United States
2007-02-12 14:41:06
jamie foggon:

> I was talking purely from the vendors perspective.

That *is* the problem and that's why we have
checks&balances in the form of
contractual agreements, instead of faith-based
"commitment to ethical
behavior" ad hoc relationships. As a vendor, of course,
your job is to
maximize your gain and zero out your risk. Terms of a
contract is the mutual
understanding of that actuality in the context of a given
project.

----
Ziya

"If I had asked my customers what they wanted,
they would have asked for a faster horse." -- Henry
Ford


------------
IA Summit 2007:  Enriching IA
Rich Information, Rich Interaction, Rich Relationships
March 22-26, 2007, Las Vegas, NV
www.iasummit.org
-----
When replying, please *trim your post* as much as possible.
*Plain text, please; NO Attachments

Searchable Archive at http://www.in
fo-arch.org/lists/sigia-l/




________________________________________
Sigia-l mailing list -- post to: Sigia-lasis.org
Changes to subscription: http://
mail.asis.org/mailman/listinfo/sigia-l

Re: Pricing the Design Process
country flaguser name
United States
2007-02-13 06:10:08
At 03:41 PM 2/12/2007, Ziya Oz wrote:

>That *is* the problem and that's why we have
checks&balances in the form of
>contractual agreements, instead of faith-based
"commitment to ethical
>behavior" ad hoc relationships. As a vendor, of
course, your job is to
>maximize your gain and zero out your risk. Terms of a
contract is the mutual
>understanding of that actuality in the context of a
given project.

Huh?

I thought that as a "vendor" my job was to deliver
value to the 
client, often resulting in or nurturing a long-term
relationship, and 
to do so in a business relationship offering adequate
compensation to 
sustain a long-term relationship.

Not lost in my mind is also a desire to have fun, explore
new areas, 
view my client's work space as my social laboratory.

Arthur

          ARTHUR FINK Consulting  arthurarthurfink.com
          ---------------------------------------------
           Ten New Island Avenue  Listening to users
       Peaks Island, Maine 04108  Designing for people
              www.ArthurFink.com  User interfaces that work
207.766.5722  cell 207.615.5722  Progress training +
consulting

------------
IA Summit 2007:  Enriching IA
Rich Information, Rich Interaction, Rich Relationships
March 22-26, 2007, Las Vegas, NV
www.iasummit.org
-----
When replying, please *trim your post* as much as possible.
*Plain text, please; NO Attachments

Searchable Archive at http://www.in
fo-arch.org/lists/sigia-l/




________________________________________
Sigia-l mailing list -- post to: Sigia-lasis.org
Changes to subscription: http://
mail.asis.org/mailman/listinfo/sigia-l

[1-3]

about | contact  Other archives ( Real Estate discussion Medical topics )