December 30, 2009, 05:29 PM —
Software developers, web designers, and other IT professionals who are trying to build up a consulting business are often asked to provide the prospective client with a formal proposal explaining how they'll serve the company's needs. If you're new at this, you may be amenable but also unsure what to actually say. Let me give you a little guidance.
Anybody can use open source. You might depend on open source software if you're responsible for IT in a large enterprise or as a consumer who prefers FOSS apps for her own personal computing needs. That's true whether you're simply a software developer contributing code to the open source project, a techie who customizes software that just-so-happens to be open source (such as a web developer building sites using Drupal), or an end user who appreciates the price (free!) and quality of FOSS apps.
However, while I'm not sure whether the statistics back this up, by my observation the open source community has a higher-than-usual percentage of consultants, value added resellers (VARs), design studios, and other "independent" techies who pay the rent by making a client happy. This blog post is directed to them. (This is nominally part of my random series on building a career in open source. It is the other side of the writing a résumé issue since consultants rarely need such documents to get work.)
My suggestions also might be helpful for staff developers and designers serving an internal audience. After all, as Jerry Weinberg pointed out in my most-favorite consulting book, Secrets of Consulting, anyone who offers advice is a consultant. However, mainly I'm talking to techies who, on a part-time or full-time basis, intend to get paid (by someone other than a full-time employer) for making software work.
The problem that techies have is that they want to talk about and use technology, and they hate having to "sell" anything — particularly themselves or their skills. Often, or at least to begin with, the work comes to them, either because they've developed a reputation for excellence ("My brother-in-law says you're good at creating websites") or because of a relationship with another techie who needs assistance ("A client asked me to take this on and I'm already busy; could you write the back-end code and I'll deal with the company?"). That's fine — and with the right connections you can make a living that way.
But at some point, a prospective client will ask you to give them a proposal. For example, a client may tell you what they have in mind, and end with, "Could you put together a proposal for the project, broken down by cost for the individual components?" You're willing, but sheesh, what are you going to say?
Proposal writing is an art unto itself, and I don't promise to be brilliant at it. I'm sure you can find how-to books at your local library, though back when I needed to write these documents regularly, I found the "write a proposal" books were tuned more for people writing government proposals worth millions of dollars, not a solo practitioner or small business trying to win a deal. The books were overkill, then; perhaps they're better now.
However, I did eventually learn the skill, and it got me plenty of consulting work and related gigs. This advice is what worked for me. I don't promise it's best from you, but maybe it will get you started.
There's a few distinct parts to a proposal. Length is rarely an issue — the proposal can be four paragraphs, four pages, or forty pages — but it usually covers the following:
Identify the problem. Describe the solution, and the steps to get there. Explain why you're the right person to do it. Tell them what it costs. The key part is to figure out what your prospective client wants — a matter of empathy and research. What problem do they want to solve? In the proposal, you restate the problem in your own words, backing up how you'll help them achieve their goals. In other words: "You say you want a site to serve left-handed beer brewers with editorial content that'll draw them to your e-commerce site where you sell left-handed equipment; here's what I'll do to help you succeed."
The hard part is to get into their heads. If you understand what success looks like to them, then it's mostly a matter of explaining what the steps are to get there (and pointing out how each step, or component, helps move the site towards their goals). There's several good reasons to include the problem description. One of them is to show the client that you were listening and that you understand their pain. After all, if you got the wrong idea in your head about the problem to be solved, you probably can't deliver something that will make the client happy.
If you can't write that "problem statement" then recognize it as a danger sign. It may mean that they blathered for an hour but you never understood the goal ("What does 'success' look like to this client?"). It may mean that the client doesn't actually know what they want — an extremely common situation. (Determining what the client actually wants is a mysterious subject best left to another discussion. One that includes a lot of beer.) But this is not only about client cluelessness; it's also a way for you to establish your own project guidelines. If you find that it's hard to answer, "What's the problem here?" you may need another round of user interviews, which is why I recommend that you don't write the proposal the night before it's due. (Not that I'm speaking from experience, you understand.)
The last two steps in the proposal are relatively easy. You probably know why you're the right person to solve the client's problem ("I've done lots of stuff like this before, and here's the references to prove it"), and "how much it costs" is just a number. How to reach that number, i.e. "How much should I charge?" is yet another discussion, but in proposal terms it's easy: This is what it'll cost you. If you've done your work well in the rest of the document, the implication will be, "...and I'm worth every cent."
The meat of the proposal is explaining the solution you think is best to solve their problem.
As a techie, you may be tempted to give the prospective client a vague arm-wave about the technologies you use, links to previous sites you worked on, and a laundry list of what would be involved for the project. ("I'd set up your DNS, install the software, create a custom theme....") There's a temptation to write the proposal as if it's a To Do list you'd show another software developer. Don't. Few clients will have the first idea of what you're talking about. All you'll do is demonstrate that software people speak gobbledegook and cannot be trusted. You won't get the assignment.
You'll note that none of this discussion, so far, has been about open source. There's a reason for that: It generally isn't a big part of the proposal. (But lots of open source consultants think it has to be, which is why the topic is relevant.) Here's the part that the FOSS people care about: You might be tempted to turn the proposal into a chest-beating document extolling the virtues of the open source (or other) technology in which you specialize. And, if you're certain you know don't know how to sell, you might copy-and-paste descriptions from the FOSS project documentation and clutter it up with other people's praise of the open source software you'll use.
Again: Don't. You'll have expended your effort on selling the open source philosophy instead of selling your blazingly brilliant software design and development skills. Either the client won't care that you use open source (because what they want to buy from you is a working solution, and they don't care about the box it doesn't come in), or you'll sell them on open source but forget to sell them on you. And you still won't get the assignment.
Clients want their computing problem solved with the ease of getting a pizza delivered: call a number, tell them what you want, and it shows up soon afterward. The ingredients you use in the pizza rarely matter to the hungry person who wants dinner. (When they do quiz you on the software you'll use, that's the time to bring out the open source marching band and play up its benefits. Usually, their qualms are answered when you say, "It's saving you money since I don't have to charge you for a software license, too." But you'll be amazed at how little clients care.)
Instead, the proposal should identify functional categories. That is, a proposal to build the client's website might have one stage in which you establish the Site Structure (which includes setting the DNS, installing software), another for design issues (working with client to identify custom themes, choose photos), still another for content creation functionality (get existing content uploaded, teach them how to use the system), perhaps a stage for getting the site noticed (SEO, etc.). Describe those steps in English with headings that your most non-techie relative would understand. You might care whether "install Askimet" goes into "Site Structure" or a different category, and you may want to document it in that section (under a "tools" list) if the proposal will also serve as the starting project spec (it often does). But each functional category should represent a stage in the project, accompanied by a paragraph that explains how it contributes to the client's goal. (Everything keeps coming back to that.)
Each phase also gets a time estimate and what it depends on (e.g. "4-6 weeks, starts after design signoff, requires meetings with client's marketing director"); some of this may be included in the consulting contract, which is usually but not always a separate document.
When possible, organize the phases based on the personal interaction necessary. Some chunks of project functionality require the client's input; those are the bits that I'd prefer to bill on an hourly rate or estimate with a worst-case view (meetings are scheduling pains, and you have less control over them: "Oh sorry we put that off until next week!" leaving you twiddling your thumbs). Other project phases let you work alone, without client participation (such as the DNS and installation stuff, which you're probably comfy enough with to bid on a fixed price). Whether or not you say so explicitly in the proposal, at the end of each function there's a clear product: a live site ready for content, a wireframe with a client signature, a system to track site analytics. (Do find some way to get them to sign off on each phase... but that's a getting-paid issue rather than proposal writing skill.)
Or to think of these functional categories another way: Break it up into sections that let you invoice regularly. If nothing else this means you could finish one piece of the project, invoice for it — and see if they actually pay on time. And if everything went to hell in a handbasket, they'd have that one part "done" without you needing to talk to them ever again. (Can you tell that I learned to plan for worst contingencies?)
I recommend that you include an optional phase that you think they client doesn't really have to have for the project to achieve success. Some clients need something to throw out; it seems to give them a sense of power to say No to something, and you don't want them doing that on something vital. But it shouldn't be really silly because they might want it, and it shouldn't make you sorry you offered. ("Social media services" perhaps?) Also, if they decide that they want you but can't afford everything you proposed, it lets you knock an item off the list and reduce the price without making it seem like you're cutting your rate.
Don't worry about the granularity of what you propose. I've known people who worry that the client will use your brilliantly-written proposal as a spec that they hand over to another consultant (who presumably will do it cheaper because you did all the hard design work). This does happen occasionally, but you have to learn to take it as a gift from the universe. If the client is so unethical or clueless as to imagine that's okay, almost certainly they would qualify as a client from hell.
There's more to successful proposal writing, I think, but that should be a start for those who are new to the game.
(Note: Inspiration for this post came from a thread on the Wise Women discussion lists. It's a high-volume, supportive, friendly community that I heartily recommend.)
You probably should follow me on Twitter. Because, y'know, you just should.
Sign up for ITworld's Daily newsletter
Follow ITworld on Twitter @IT_world
This is by no means a comprehensive tutorial on the subject but there are some very good ideas in this article to digest. I will try to compose something on the topic soon.
No comments:
Post a Comment