Google Groups Home Help | Sign in
Dealing with very large clients
There are currently too many topics in this group that display first. To make this topic appear first, remove this option from another topic.
There was an error processing your request. Please try again.
flag
  20 messages - Collapse all
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
Nick Coyne  
View profile
 More options Jun 15 2007, 12:59 am
From: Nick Coyne <nic.co...@gmail.com>
Date: Thu, 14 Jun 2007 21:59:50 -0700
Local: Fri, Jun 15 2007 12:59 am
Subject: Dealing with very large clients
We're pitching on the web and digital marketing for the South African
division of a Fortune 500 company. The RFP is over 150 pages long and
the proposal will no doubt take days to complete.

Almost everything in the RFP points to risk-minimisation, with clauses
such as a $50,000 penalty should the launch date for the new website
be missed, for example.

Now if this was a normal project, the website would probably only cost
about $50,000, but considering all the overhead that we'd have to
carry to satisfy their risk aversion (more staff, etc), and also the
very stiff penalties that delays could incur, I'm thinking that we'll
have to charge a lot more than we normally would.

Does anyone have experience dealing with companies like this?


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Robby Russell  
View profile
 More options Jun 15 2007, 9:31 am
From: Robby Russell <ro...@planetargon.com>
Date: Fri, 15 Jun 2007 06:31:59 -0700
Local: Fri, Jun 15 2007 9:31 am
Subject: Re: [rails-business] Dealing with very large clients

On Jun 14, 2007, at 9:59 PM, Nick Coyne wrote:

> We're pitching on the web and digital marketing for the South African
> division of a Fortune 500 company. The RFP is over 150 pages long and
> the proposal will no doubt take days to complete.

If you're spending time discussing their project, you should be  
incorporating this into your cost. We almost always charge them to go  
through a formal proposal process. This is what we call an ITER-ZERO  
phase, and we charge for this process, because our aim is to provide  
more value to their project through our discussions with them.

One could argue that a consultancy could take the risk and do it for  
free, but if you're reviewing their documentation and making any  
suggestions as to how to improve upon their proposed solutions...  
then they get to walk away with that for free. You could then argue  
that you just save your new ideas until you win the contract, but  
perhaps this is an important selling point for you.

In our case, it's been part of our selling process and because of how  
busy we've been over the past few years, it's been a good way to  
filter out potential clients that aren't willing to pay to have  
someone give them a meaningful analysis of their project  
proposal. ...and I can speak from experience. There are many  
companies that will pay you for this process. You just need to ask  
them to do it.

> Almost everything in the RFP points to risk-minimisation, with clauses
> such as a $50,000 penalty should the launch date for the new website
> be missed, for example.

I would review this very carefully. Given that they want to minimize  
the risks, I would have a lawyer review this and propose changes. For  
example, is their a $50k bonus for delivering it early? This isn't  
unheard of.

> Now if this was a normal project, the website would probably only cost
> about $50,000, but considering all the overhead that we'd have to
> carry to satisfy their risk aversion (more staff, etc), and also the
> very stiff penalties that delays could incur, I'm thinking that we'll
> have to charge a lot more than we normally would.

Without knowing more about their project, I can only offer so much  
advice. Mainly, try to avoid providing a flat bid on projects. Stick  
to ballpark estimates and insist on a time and materials contract or  
a hybrid of short 1-2 week iterations with a cost for each, depending  
on the deliverables within each iteration.

Anyhow... running late to work.... but wanted to send over some of my  
thoughts from my experience in these situations.

Cheers,

Robby

--
Robby Russell
Founder and Executive Director

PLANET ARGON, LLC
Ruby on Rails Development, Consulting & Hosting

www.planetargon.com
www.robbyonrails.com

+1 503 445 2457
+1 877 55 ARGON [toll free]
+1 815 642 4068 [fax]


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Paul Pagel  
View profile
 More options Jun 15 2007, 9:58 am
From: "Paul Pagel" <paulwpa...@gmail.com>
Date: Fri, 15 Jun 2007 08:58:32 -0500
Local: Fri, Jun 15 2007 9:58 am
Subject: Re: [rails-business] Re: Dealing with very large clients

On 6/15/07, Robby Russell <ro...@planetargon.com> wrote:

Agreed.  The contract should be inventively beneficial for both parties.

> > Now if this was a normal project, the website would probably only cost
> > about $50,000, but considering all the overhead that we'd have to
> > carry to satisfy their risk aversion (more staff, etc), and also the
> > very stiff penalties that delays could incur, I'm thinking that we'll
> > have to charge a lot more than we normally would.

> Without knowing more about their project, I can only offer so much
> advice. Mainly, try to avoid providing a flat bid on projects. Stick
> to ballpark estimates and insist on a time and materials contract or
> a hybrid of short 1-2 week iterations with a cost for each, depending
> on the deliverables within each iteration.

I agree to avoiding flat bidding.  It is never accurate enough bidding a
project up front.  We have it written into our contract we get bonuses for
delivering features early and make less for delivering features late on an
iteration by iteration basis.  The client has embraced this method and it
creates a tension and motivation for every iteration.

Now big business can't fly by the seat of its pants on an iteration by
iteration basis, so we give epoch estimates.  These are blocks of related
features and about how many iterations they will take.  The client has to
understand they are not that accurate, due to the nature of an agile
process, the requirements WILL change.  Building up something from the
ground up, you learn more than top down.  So, we will re-estimate upon
client request.  There defiantly needs to be some level of trust between the
client and contractor to make this work though.  You can't add every
scenario into the contract.

Anyhow... running late to work.... but wanted to send over some of my

Paul W Pagel
www.8thLight.com
blog.8thLight.com

    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Nick Coyne  
View profile
 More options Jun 15 2007, 11:17 am
From: Nick Coyne <nic.co...@gmail.com>
Date: Fri, 15 Jun 2007 15:17:52 -0000
Local: Fri, Jun 15 2007 11:17 am
Subject: Re: Dealing with very large clients
Thanks for the suggestions.

Unfortunately this is one of those where its explicitly mentioned that
there's no fee payable for the proposal, and if we don't like it,
tough. The detail of the RFP is insane - we are expected to provide
costings, staffing, etc, etc, etc for the next 3 years (the duration
of the contract). I feel like I'm quoting on redesigning their central
database, where the world would end for 100,000 employees if we got it
wrong.

Half of me is saying "forget it, its too much effort, and we won't get
it because we're not corporate enough", and the other half is saying
"do it, you might learn something!"

Cheers
Nick

On Jun 15, 3:31 pm, Robby Russell <r...@planetargon.com> wrote:


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Robert Dempsey  
View profile
 More options Jun 15 2007, 11:58 am
From: Robert Dempsey <robertonra...@gmail.com>
Date: Fri, 15 Jun 2007 15:58:52 -0000
Local: Fri, Jun 15 2007 11:58 am
Subject: Re: Dealing with very large clients

> Half of me is saying "forget it, its too much effort, and we won't get
> it because we're not corporate enough", and the other half is saying
> "do it, you might learn something!"

Nick,

At ADS we normally stay away from RFP's as the prospect can take
whatever ideas you give them and use them with someone else.
Responding to RFP's take a LOT of time and effort which, unless you
can recover the cost, might be lost. I know some companies have
template responses that they can use which makes the process simpler,
however for us smaller folks, it is just a lot of grind work. Good
luck.

Robert Dempsey
http://www.techcfl.com
http://www.railsforall.org


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Robby Russell  
View profile
 More options Jun 15 2007, 12:13 pm
From: Robby Russell <ro...@planetargon.com>
Date: Fri, 15 Jun 2007 09:13:26 -0700
Local: Fri, Jun 15 2007 12:13 pm
Subject: Re: [rails-business] Re: Dealing with very large clients

On Jun 15, 2007, at 8:17 AM, Nick Coyne wrote:

> Thanks for the suggestions.

> Unfortunately this is one of those where its explicitly mentioned that
> there's no fee payable for the proposal, and if we don't like it,
> tough. The detail of the RFP is insane - we are expected to provide
> costings, staffing, etc, etc, etc for the next 3 years (the duration
> of the contract). I feel like I'm quoting on redesigning their central
> database, where the world would end for 100,000 employees if we got it
> wrong.

> Half of me is saying "forget it, its too much effort, and we won't get
> it because we're not corporate enough", and the other half is saying
> "do it, you might learn something!"

We've turned away some _really_ large projects because of concerns  
like this. Sometimes it's okay to step back and evaluate the whole  
thing. Do you really want to be working on the same project for three  
years? How does the rest of your team feel about it?

Good luck with your decision making process!

Robby

--
Robby Russell
Founder and Executive Director

PLANET ARGON, LLC
Ruby on Rails Development, Consulting & Hosting

www.planetargon.com
www.robbyonrails.com

+1 503 445 2457
+1 877 55 ARGON [toll free]
+1 815 642 4068 [fax]


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
keeran  
View profile
 More options Jun 18 2007, 9:45 am
From: keeran <kee...@gmail.com>
Date: Mon, 18 Jun 2007 13:45:58 -0000
Local: Mon, Jun 18 2007 9:45 am
Subject: Re: Dealing with very large clients
Have you spoken with the person in charge of the tendering process?
I'm on a mailing list for local public sector notifications, and
almost every alert I see has clauses for delivery guarantees, company
history, professional indemnity etc. Most of them are boiler plate
entries that can be negotiated down/away once you have established a
relationship with a real person handling the project.

Sound advice from Robbie by the way - think about what you want to be
doing in 2-3 years time and ask yourself if this project fits into
those plans.

Also, if they're not willing to pay for your proposal (yet they have
$50K penalty clauses) it makes the whole scenario smell 'off' to me -
be careful!

k

On Jun 15, 5:13 pm, Robby Russell <r...@planetargon.com> wrote:


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Discussion subject changed to "I introduce myself and ask for help" by Mustafa Ekim
Mustafa Ekim  
View profile
 More options Jun 18 2007, 10:16 am
From: Mustafa Ekim <ekim.must...@gmail.com>
Date: Mon, 18 Jun 2007 17:16:57 +0300
Local: Mon, Jun 18 2007 10:16 am
Subject: I introduce myself and ask for help
Hey everybody,

I am 24 years old boy, Mustafa Ekim, from Istanbul / Turkey.

I have graduated from university on 2006, and done my military service
this year. Now I'll start working on a IT company in Turkey which mainly
focuses on mobile applications.

Even though I am not a software expert & engineer, I really impressed by
rails last year. Since that time, I am trying to create my application.

When I were a student, I always learned that I should draw ER diagrams,
Data Flow Diagrams, UML diagrams etc. to be certain that the project is
understood correctly by everybody in the same way. And it is always said
that these documentation steps are very very critical for the success
and sustainability of the project.

However, even though I've read at least 2 rails books, I never see an ER
diagram or UML diagram. So the question is, in the business life, do you
use these steps? Or these steps are not usable in practice? How do you
design your application?

Any readings or books for this stage of rails development will really
help me.

Thanks

Mustafa Ekim


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Discussion subject changed to "Dealing with very large clients" by dasil003
dasil003  
View profile
 More options Jun 18 2007, 10:29 am
From: dasil003 <gabrie...@gmail.com>
Date: Mon, 18 Jun 2007 14:29:07 -0000
Local: Mon, Jun 18 2007 10:29 am
Subject: Re: Dealing with very large clients
I don't have any experience working on this type of project, but I do
have experience in huge organizations.  And my advice would be to very
very careful about what responsibilities you take on.  When big
projects fail, it's often due to corporate politics, or just a
complete lack of understanding of the business goals or actual needs
being met by the project.

As a developer it will be your job to cut through the bullshit and get
what you need.  But if the project is not well-conceived, or there's
any kind of internal conflict, you may well become the scapegoat for
the whole thing blowing up.

The first order of business is to get some sense of the real people
involved.  If you don't feel comfortable with them then get out now!
It's understandable that they would want risk mitigation on their end,
but also consider risk mitigation from your end.  If they think a 150-
page RFP is enough for you to deliver a successful product, then
that's a big red flag to me.

On Jun 14, 10:59 pm, Nick Coyne <nic.co...@gmail.com> wrote:


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Discussion subject changed to "I introduce myself and ask for help" by Robert Fischer
Robert Fischer  
View profile
 More options Jun 18 2007, 10:34 am
From: Robert Fischer <robert.fisc...@SmokejumperIT.com>
Date: Mon, 18 Jun 2007 09:34:27 -0500
Local: Mon, Jun 18 2007 10:34 am
Subject: Re: [rails-business] I introduce myself and ask for help
I've found the real value of formal diagrams to be in creating them --
like a mathematician writing out a proof, it really forces you to think
through the design.  It's also an OK way to try to get a grip on source
code that I'm not familiar with.

As a tool for business communication, though, I've not encountered one
which I particularly like.   Even moderately complicated designs end up
being either 1) a mess of tangles, and/or 2) a spray of disparate
clumps.  There is just enough technical information in the diagram to
require some skill to read it (thereby limiting the audience and
creating potential confusion), yet not enough to catch implementation
details (thereby missing out on the biggest value of being technical).  
For business communication, I prefer to use tools like FIT
(http://fit.c2.com/) and lots of demonstrations.

Most of my design -- particularly with a framework with "natural paths"
as strong as Rails -- is sketched out with arbitrary boxes and arrows.  
I've learned that if I put too much more effort into it, I'm going to
over-architect the solution, and I'll actually end up being less
productive.  Worse, sometimes I'll put so much effort into the boxes and
arrows that I'll forget that my contract is with the customer, not with
the boxes and arrows.  Once I have the few sketched out boxes and
arrows, I let the design emerge from the customer requirements and the
practice of writing unit tests: I build things as I need new
functionality or need to decouple code for testing.

Robert Fischer
IT Firefighter
Smokejumper Consulting


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the