**NOTE: Read at your own risk - If you don't understand, appreciate, or are otherwise not keen on satire, please leave now ;) **

Reviewing competing proposals is not uncommon in my day-to-day, especially with existing clients who are shopping for a new build after a number of years. I have to admit, I've been absolutely inspired by the quality of some work that has come across my desk in this regard. So inspired, in fact, I've almost felt a fear in me not to proceed with my counter-proposal.

But, I'm a fighter.  So instead of cowering under my desk as I've threatened to do so many times before, I took this is an opportunity to learn and apply some new techniques to my current work process. 

The following is a combined list of my observations and recommendations on how to write a proposal that's a guaranteed winner:

1. Techy words are scary and sound self-important. Use them frequently, especially out of context.
   - Normal people love to feel lost in a sea of unfamiliar words and impersonal half-thoughts. They also love reading paragraph after paragraph about the inner workings of a build: plug-ins, taxonomies, you name it. Littering your proposals with jargon is guaranteed to flood your business with willing clients.
2. Spend at least 40% of your proposal saying bad things about the current build.
   - Never mind the fact the client came to you with a list of current gripes. Maybe they were already aware that their site was old and doesn't do what they need any more. Don't waste your time getting the prospect excited about a new solution; just keep beating the dead horse. It works every time.
3. Spend another 20% filling pages with lofty buzz words and fluff. 
   - Tell them about how they need a "website 2.0+ redesign" built on "software that will be everything you want it to be" and how you're going to "set up a social network" as part of "providing a very powerful internet marketing experience." - (note: the more you can write like a non-native speaker, the better) 
   - Here's another great one that plays on #1 as well: "your software shouldn't be limited to itself. The user should also be able to pull in multiple API's, creating a whole new user experience and making the site totally user-driven"
4. Misinform as much as you can
   - Clients love to be mislead, especially when they come to you because they trust your expertise. Not sure about a subject or if it even applies to what you're quoting? That's fine!! Just make it up as you go!!  This is especially great as you will begin to discredit other developers in the process - as the prospect swallows down your false rhetoric, everyone else will begin to leave a bad taste. More work for you! Yay!
5. Don't let the client know why any of what you're saying is of value to them.
   - Tying the first 4 points together, it's incredibly important that you produce bullet point after bullet point of semi-related facts and quasi-important observations without telling the client how it affects them.  Don't ever mention helping attract new customers or using content to direct qualified users into the sales funnel. And never, EVER speak to them in terms they understand.  Clients absolutely hate to be told how investing in a website is going to help their brand or their business, especially when you do it clearly and with purpose.
6. Whatever you do, don't encourage the client by speaking as if you are the ones who will provide that value.
   - In case you do slip up and mention how your work is of value to the client, at least make sure not to give them the idea that YOUR work explicitly is the best fit. Use the third person and speak in a passive voice: "your developer would need to" "the website should" -- saying things like "we will do X to give you Y" or "we've had A results with related B, we are excited to C for you" is a terrible idea.  Talking about the project like it's already yours is an even worse one.

To sum it all up: talk out your ass and don't bother thinking about, much less addressing the client's needs. I mean, they came to YOU for work because they can't do it themselves anyway. Who cares if you give them a reason to stick around?

It's not like there's others out there who are going to take the time to make that client understand and feel good about their investment. There's definitely no one out there ready to build a lasting relationship by taking a genuine interest in the prospect's ultimate success.

...

That said, let me leave you with what is one of the greatest compliments I've ever been paid, by what is one the best clients I will ever have:

"If I could meet some of these developers, I'd kick them in the teeth myself! ...

...not you, Casse. You actually know how to talk to PEOPLE."

Listen.

An architect doesn't ASSUME there will be a door on the building; She draws it in the blueprint.

Why?

Two reasons:

NUMBER ONE:  Drawing on the blueprint gives her control of the vision.

Not only does she say "I need a door." But, by drawing it into the spec - she says "I need a door, and I want it here - and I want it to look like this"

And so then maybe the client says, "Nice door, but I was thinking we could change it this way" - and it's ok because she can change that spec before they build.  Or maybe the client says, "Actually, I don't really want a door. I want a secret tunnel from the back yard. You know, like the pyramids...?"

Any way it goes, the point is she took control and lead the discussion.

NUMBER TWO:"Obvious" is subjective.

Builders don't build what isn't on the blueprint, and they don't ASSUME to build it anyway because "it's obvious."

It also makes the architect look like a real winner (READ: idiot!) to the client when she "assumes a door is obvious" and leaves it off the spec.

...
 

So, what the hell do doors and blueprints have to do with web development?

only EVERYTHING

An architect wouldn't assume a door because it's "obvious," so why would you make assumptions in a project scope?

Seriously.

We take for granted the simple things in our little web world.  The things that are obvious to us. User login functions, site maps, Twitter buttons - What. Ever.

...If you think "it's obvious" - you're wrong.

...If you assume "well yeah, of course" - write it down anyway

...If you're not quite sure - ask the question. CONTROL THE DISCUSSION.

The Moral of all this? Never. Assume. Anything.

Using "obvious" as a crutch leads to mistakes, ugly builds, and heartache down the line. Leaving "obvious" out of the spec is one of two things: Careless or stupid.

In the end you either lose control of the vision, or you look like an ass for forgetting. Or both.

I've kept myself calm over the past few days by busying myself with the small tasks I can control amidst the chaos I couldn't.  Between the "hurry up and wait" I did my best to "take a breath and do."  Those little things became a natural inspiration for this week's Thankful Four Wednesday.  Today my thankfulness is all about things on my to-do list that I can control. That list in its entirety includes everything from "how dirty the toilet is" to "what color that page background will be." To spare you all the gory ugly, I'll just give you 2 work related and 2 not-so-much...

Thankful Four: Things I Can Control

1. SEO/ SEM Reports - It happens that the 1st of the month fell in the middle of my messy week.  I am thankful for having those two days each month where I buckle down, review some dynamically generated graphs and tables - write some notes about campaign performance, and send them on their way.  I write the recommendations and make the campaign changes. I control the report.
2. Housework - This may sound silly, but for me, house chores are a quick escape when I feel everything else has gone terribly wrong. I can do the dishes.  I can vacuum the floor.  I can fold laundry. I can unpack boxes and make beds. Even in the insomnious wee hours, I control the cleanliness of my house.
3. Site Builds/ Frameworks  - Unlike the instability of antediluvian hardware and ornery, indecisive clients: I can control the structure and outcome of the code I write code.  I can also handle the more-predictable side effects of upgrades and new installations. Even when things go a little wonky, I can handle their issues. I can minimize the damage.  As I like to say - I don't break things.  I generate new errors.  I can control the code.
4. Dinner - Even if I don't cook it myself, I don't typically find myself strapped to seat being force fed some unpalatable swill. Well, there was that one time in Santa Ynez ... I mean ... uhhh ... yeah...  When all else fails, I can at least find comfort in the fact that I control what goes into my belly.

Face it, Life is a cacophony of maybes and it's-a-matter-of-whens.  It's important to keep yourself stable by remembering what things you can control.

...what are some sanity-stabilizing little things you are thankful for being able to control amid the chaos?

I wasted almost five hours of my life this morning because of the (what I consider to be) poor choices of the person in my position before me.

Five hours of playing IT-for-free when I could have been doing my "real" job building a billable web project.

Five hours of learning about something that, although related to my day-to-day, doesn't serve me as much more than a tertiary bullet point on the laundry list of my career goals.

Five hours that skewed the day so badly it was hard to accomplish anything relevant in the afternoon.

Five hours of pain I wouldn't wish on my worst enemy.  Not even that person-before-me who ultimately made today possible.

And while I'd like to discuss all the events that led to today's debacle - I'm focusing my first Don't Be Stupid Tuesday post on what I think is the most important point of the lot because I think it's the easiest to accomplish.  And, that's the importance of appropriately documenting your project for future reference and maintentance, whether its for you or whoever comes along to take care of it next.

This isn't the same-forever-only-2-people-know Coke Secret Formula. This is a live build that real, normal people need to use in every day situations. It needs to be adaptable, fixable, and understandable.

I shouldn't even have to say this, but the number of issues I hit with things I didn't build - issues that would have been moot with the right notation - issues that are normal concerns of someone in my position, managing the care of 100+ sites, and building new constantly ...I don't know how to stress the importance of taking that little extra time to DOCUMENT YOUR SHIT.

Comment your code. Provide a README or similar notation.  Tell someone else where you keep your list of passwords. I'm not saying publish it to your Facebook - be smart about it. And whatever it is, consider the person that may be fixing it later: a PHP file may need some commentary to suit another developer, but a mail server may need some direction in layman's terms in case the IT is out of the office. 

Point is, whatever you've put together, you're not going to be there forever to take care of it. And even if you are, who's to say there won't be a day some catastrophe hits and you're not there to troubleshoot, or maybe 3 years go by and you plumb forget what you did in the first place. It happens.

I mentioned earlier that this was the easiest to avoid of all the causes of today's mess-i-wouldn't-wish-on-anyone, and I stand by that statement. Stop leaning on excuses, and start breaking the bad habits.

I'm not just asking for my own sake as the "person that fills your shoes next."  Do it for your development as a professional. As someone who cares about being a Senior This, a Lead That, or simply a hard worker who is seen as a competent, accountable whatever you are.  I know when you stop and think about it, you'd hate to be in my shoes: wasting time, keystrokes, and sanity on things that could, and more importantly SHOULD, be much less stressful.

I'm even willing to bet you've already been there once or twice before.

3.27 minutes ago, I finally resolved an issue that could have been avoided with the proper documentation.

3.27 minutes ago, I felt torn between having lost 4 hours of my life and being "grateful for the experience."

3.27 minutes ago plus the four hours prior, I was painfully reminded, as I am all too often, of the importance of thinking outside the moment you're standing in - especially as a programmer or anyone who creates something to be used, tweaked, and interpreted by future custodians.

3.26 minutes ago, Don't Be Stupid Tuesday was born.

Starting this afternoon, and every Tuesday to come to uncertainty, I will post for your pleasure (and hopefully your empathy) my musings on the small things in life you can focus on to make yourself a little less "stupid."

That is, I want to share some antecdotal -let's call them "recommendations"- on how one might go about functioning well in a world that has OTHER PEOPLE IN IT (besides just you!) A commentary on how to better yourself as a functioning member of society, if you will.  Most of these tips will spawn from my specific adventures as a php-developer-slash-swiss-army-web-everything, but I hope that even if you don't speak the same flavor of programese as me (or, if you don't speak it at all), you can still take something away from the whole mess of it.

I hope you'll share comments or recommendations on future posts I can plug into this category.

Subscribe to this blog or simply look for my #stupidtuesday posts on Twitter to join in the fun.

And please, don't hesitate to share some #stupidtuesday of your own!