Stop Writing Project Proposals | Hacker News Reader

Stop Writing Project Proposals

smashingmagazine.com

80 pointssuperchink13 comments

I can't speak for development work, but for consulting work this is fantastic.

We completely turned my old business around using this. We went from fighting to sign 3k/month retainer clients to signing multiple 8k, 10k, 12k and even a 17k month retainer using this strategy.

In my experience, the clients that don't like this arrangement are the ones that end up being bad clients down the road anyways. The ones that do like this, see the value in seeing an expert evaluation of the problem before spending lots of money to fix something they haven't yet identified.

While a bit simplistic in the description of how much you can lock down scope with an initial requirements document, the main point, which is to get paid for an initial analysis and design phase, is incredibly important for small consulting shops.

If you do not do this, you are merely rolling the dice every time you take on a project, and the odds are not stacked in your favor!

While I agree this is a great idea (as opposed to shooting-from-the-hip on proposals), be careful of putting too much faith in the process. From the article:

While how one calculates the price may vary, all the information is now available to see the project through from start to finish, identifying the challenges, and determining the amount of resources required to meet the project’s objectives.

That sounds like an old fashioned waterfall fantasy to me. I know it's not true, but I'm afraid clients would believe it.

I always say something like, "here is your project evaluation, based the current desires/spec for your project. Certainly things can be add, removed, re-prioritized. When work begins this should be seen as a living document that grows and evolves with the project."

The initial evaluation will help you fill out your client's backlog, and also understand how many people (with what skillets) you need on the project.

So, think of it as getting paid to do Agile Project Manager work. At least how I see it. :-)

Interesting take. Isn't that, in practice, the same as just refusing to enter non-paid competition and taking an advancement for every project? The work put into the "evaluation" sounds like information architecture + tech specs + development planning, which would normally answer for 30-50% of a project's cost. I wonder if marketing this phase as an independent package makes a difference in sales, as he appears to suggest?

It makes things a lot easier in a way for both ends. You're not tied long-term to a client that could potentially be a nightmare. You get to evaluate the project and give them a realistic view of what work comes next. You can also (and should occasionally) turn down the job, if the evaluation reveals they're not a good fit for your services.

Forgive me if I've misread the article, but isn't the Project Evaluation essentially just a spec, with the option to actually implement the spec or not?

I think the difference is that a proposal is "here's how I would implement your requirements as documented" while an evaluation is a bit more than that. It's "Here's what problems you are having. Here's what you say you need. Here's what we think you need." and maybe "Here are a few ways we could go about helping you."

The goal is not to just deliver a proposal based on an incomplete spec, but rather to help the customer understand their problems better.

This is a great idea when dealing with small clients. The big challenge, however, is that the majority of the organizations that rely on RFP (e.g. public sector or enterprise buyers) do so because they HAVE TO for policy / political reasons. It's not only about selecting the best vendor.

The RFP process optimizes for "not making a bad choice" vs "making the best choice", and is usually also done for transparency / accountability reasons as well.

We're building a new type of eSourcing tool to help make the RFx process faster and more streamlined for vendors / buyers / evaluators, so we've been digging deep into 'structured buying'. It's a lot more complicated than "this process sucks, let's change it".

In our opinion, the problem isn't the process itself (which is necessary for public sector and enterprise) but in how the process is conducted - i.e. the lack of communication, slow decisions, ill-defined evaluation criteria, etc.

Really though I think for large clients is that it is the right way to go. For small clients, typically you have a pretty good idea of what they need. For large clients it can prevent swamp projects.

Really for the big customers, the key to doing a project evaluation is to deliver independent value in the evaluation. The evaluation may come in handy even if they do not choose to close. So here you are bringing people in, you are finding out exactly what the problems are and why, and giving the customers tools to think about those problems. Who knows, the evaluation might even cause them to rethink the project direction entirely?

One key advantage to doing project evaluations and charging for them is that you are suddenly a lot more free to tell the customer "We are happy to do this for you, but in our estimate, you don't need a fancy new CMS system at this point. The first thing you need to do is get some more editors and work on your editorial processes. Once those are under control, we can talk about a CMS."

I can speak to this. Many large clients have the ability to hand out small evaluation projects without competitive bidding. So, they can hire you to do a 10K or whatever evaluation but are required to put the resulting 100K implementation through an RFQ process.

The eye-opener for me quite some years back was discovering that most of the RFPs we saw were the result of an evaluation like the one described, we were being asked to quote, blind, against the firm that had been paid to write the RFQ in the first place.

One tl;dr of this article could be, "Stop responding to RFPs written by your competition and look for opportunities to write the RFPs yourself."

I had the same thought ten years ago. I think this is the best way to work. It was never accepted by the clients though.

Sounds great, but proceed with caution. Where I work, you would be deemed "non-responsive".

Reply on news.ycombinator.com