Dealing with very large clients
Nick Coyne
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?
Robby Russell
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]
Paul Pagel
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
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]
Nick Coyne
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
Robert Dempsey
> 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
Robby Russell
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!
keeran
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
Mustafa Ekim
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
dasil003
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.
Robert Fischer
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
Robert Fischer
paid to how to manage the failure of the project. It's not uncommon for
contractors to be brought in because the project has become anathema to
the employees, or even because the project is understood to be doomed
but is still unable to be stopped. In this case, you may be brought in
to take the fall.
This isn't always the case: in fact, my experience is that it's pretty
rare -- but it happens, so it's best to be warned.
Robert Fischer
IT Firefighter
Smokejumper Consulting
Jon Dahl
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.
Are you staffed for a project like this?
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!"
One of the most important things I've learned is to get a feel for clients and projects, and turn down the ones that give me a bad vibe. This is hard to do early on, and we took a few projects for bad clients. They were good learning experiences, but also pretty painful.
I get a bad feeling from what I've heard so far about this project. Sounds like the client wants someone they can abuse. It also sounds like they have deep pockets. If you want to try the project, and you have really skilled staff (or can staff up), I would ask for a lot of money - like US$400,000 for the initial build cycle and a few hundred thousand a year after that. After all, they want to take $50k back if the project is late, and lateness is almost a given with a difficult client.
Pick a price that gives you a ton of padding if you get the project. And if you don't get it, you're probably better off. :)
And don't do ANYTHING without a good lawyer.
--Jon
Jon Dahl
(Of course, there are plenty of Rails coders out there who think they're being Agile by not managing their projects at all. I probably used to fall into that camp. But that's another story.)
Cheers,
Jon
Mustafa Ekim
programming or extreme project management ?
I've read about agile development philosophy and now I feel better.
Thanks Jon.
Oren Golan
http://www.agilemodeling.com/essays/umlDiagrams.htm
> ( http://fit.c2.com/) and lots of demonstrations.
Rowan Hick
ERD's are almost mandatory for medium to large scale data models. As
soon as you get beyond say 10 tables and a single developer (no hard
and fast rule), it's like trying to navigate without a map.
The reason you may not have heard of them is most examples and talks
are about simple systems, you're unlikely to see the inner workings of
some enterprises's system. Eg the Agile Rails book just models a very
simple Order - OrderLine - Product relationship.
Conversely one of the apps I'm working on has 116 models at current
count. At one company we had an ERD that could wallpaper an entire
wall 3-4m wide... typically a developer would know their specific area
inside out but would refer to the diagram to see other areas of the
system.
It's a good habit to get in, modelling ERD's. UML's I find less so, as
using Rails/ActiveRecord your UML diagram would look very similar to
your ERD, except you have the additional methods exposed within your
models.
Just follow your nose, with time and experience you'll figure out the
best approach that works for you..
Cheers
Rowan
----
http://work.rowanhick.com
On Jun 19, 12:39 pm, "Jon Dahl" <jond...@gmail.com> wrote:
> As Robert hinted at, Rails developers tend to shy away from UML and the
> like. Do some research on Agile development and you'll get an idea of how
> many Rails teams like to operate. Agile and UML don't necessarily have to
> conflict, but in practice, they often represent really different
> philosophies.
>
> (Of course, there are plenty of Rails coders out there who think they're
> being Agile by not managing their projects at all. I probably used to fall
> into that camp. But that's another story.)
>
> Cheers,
> Jon
>
Robert Fischer
learning about them? Are they easy to be automatically generated? What
does "ERD" stand for?
Robert Fischer
IT Firefighter
Smokejumper Consulting
Benjamin Curtis
--
Benjamin Curtis
http://www.bencurtis.com/ -- blog
http://agilewebdevelopment.com/rails-ecommerce -- build e-commerce
sites with Rails
Nick Coyne
> Are you staffed for a project like this?
We will have to make a few hires, and also call in partners for some
parts of the work, but we think we can make it work. Whether we can
convince the client is another story :) Realistically though, we think
most of the people pitching will be in a similar position.
> Pick a price that gives you a ton of padding if you get the project. And if
> you don't get it, you're probably better off. :)
We're not going to be shy with pricing. It seems they're expecting to
pay a lot, and for the level of paperwork, documentation and systems
that they require we'll make sure its worth our while.
> And don't do ANYTHING without a good lawyer.
Definitely!
Cheers
Nick
On Jun 19, 5:06 pm, "Jon Dahl" <jond...@gmail.com> wrote:
Nick Coyne
Then I've found the following to be very useful:
http://safari.oreilly.com/0131111558
http://safari.oreilly.com/0321205685
For TDD with Rails this one's a good introduction:
http://www.amazon.com/Beginning-Ruby-Rails-E-Commerce-Professional/dp/1590597362/ref=pd_bbs_sr_1/102-3092232-5127334?ie=UTF8&s=books&qid=1182354154&sr=8-1
Cheers
Nick
On Jun 20, 2:40 am, Mustafa Ekim <ekim.must...@gmail.com> wrote:
> So, any recommendation about books about Agile development, or XP
> programming or extreme project management ?
>
> I've read about agile development philosophy and now I feel better.
> Thanks Jon.
>
> On Tue, 2007-06-19 at 11:39 -0500, Jon Dahl wrote:
> > As Robert hinted at, Rails developers tend to shy away from UML and
> > the like. Do some research on Agile development and you'll get an idea
> > of how many Rails teams like to operate. Agile and UML don't
> > necessarily have to conflict, but in practice, they often represent
> > really different philosophies.
>
> > (Of course, there are plenty of Rails coders out there who think
> > they're being Agile by not managing their projects at all. I probably
> > used to fall into that camp. But that's another story.)
>
> > Cheers,
> > Jon
>