Part 1 - Wading Into the Cesspool of Contracting-Out Work
Knowing What You Want
If you don't know what you're looking to hire someone for, holy cow, you are in for a dangerous ride! Don't let that sinking, helpless feeling consume you and sway you into thinking/believing that you can trust the person you plan to hire to help you find what you really want. And please don't confuse this with the scenario where you've been working with someone long enough already to have some trust and faith in what they recommend. I'm not talking about that situation. I'm talking about the initial engagement, your first meeting or first encounter, with the person(s) you are considering to pay to solve one of your business challenges.Even if you know next-to-nothing about applications, software, web development, web design or any of the techno-babble-mumbo-jumbo, you have Google. You have Bing! and Yahoo! and a bazillion web sites available to you to help you find what you want. There are millions of articles, blogs and eBooks to help you educate yourself on everything from the most general aspects, down to the insanely granular minutiae and everything in between. There's no excuse in this age of the Internet to remain ignorant about something you're about to shell out hard-earned money for.
Basically, the more you become familiar about the things you are looking to have done for you, the more likely you are to be able to:
- Ask intelligent questions and get meaningful, understandable answers
- Communicate your ideas within the context of the limitations of the technologies involved
- Be better-prepared to thwart bullshit schemes and scams
- Intuitively relate certain aspects of the project with complexity and cost impacts
- Impress others at social gatherings
If you don't know what HTML or XML are, good places to start are W3Schools (www.w3schools.com), or About.com, or but those are just two out of a million useful web sites that offer free, yet incredibly helpful information and examples. If your business challenge is worth paying your hard-earned money to solve, it's worth you investing a little time to become intelligent about the ways that challenge can be solved. (for the record, I have no relationship of any kind with any of the links mentioned above, nor do I reap any benefit from you going to their sites, other than that awesome, glowing feeling of knowing that I possibly helped another person learn something new).
Communicating What You Want
Check this out. This is a scenario I personally witnessed more than a dozen times in the past five (5) years alone: Customer sits down with a web developer to discuss building a new web site. Customer lists the following "requirements" for the developer to accommodate:- Must be able to update content to add "News", "Events" and photos.
- Must have a catchy, eye-grabbing animated graphic on the main "home" page.
- Must have their official company logo in the banner on every page.
- Must have a link to "Contact Us"
Developer nods in agreement, slides the SOW across the table, then the contract. Both parties sign off and the developer heads off to code away.
A few weeks later the developer says "All done! Here's your new web site!" It looks all spiffy and has the official company logo and name on the banner. It has the catchy, Flash-enabled animated graphic on the home page. There are links to "News", "Events" and "Images", and it has a "contact us" link.
The customer starts poking around, smiles and strokes the final check payment (or clicks the PayPal invoice link, etc.). After a few days of continued poking, the customer discovers that they can't seem to find a way to enter or upload "News" items, "Events" or upload photos. And the "Contact Us" link simply opens a "mailto://" link, rather than a web form with some additional options to help categorize the nature of the contact request. The customer feels somewhat frustrated and contacts the developer.
The developer reiterates the list of "requirements", and categorically insists each was satisfied according to the wording. The customer then realizes they never included details about "WHO" could upload content, or "HOW". Nor were there any specifics provided about the contact request feature. Now the developer insists that, since the original terms were met, and paid for, subsequent requests to update content would constitute additional work (service requests), and additional fees would apply. The customer is dismayed and pissed off.
Who's to blame?
You can blame the developer for not asking more thorough questions during the requirements discussion. You could also blame the customer for not stating their requirements more accurately and concisely. You would be correct on both, actually.
You might think this is a fictional scenario, but I have met so many clients that have had this EXACT same situation occur, that it's become part of my standard requirements interview topics. Additional questions to ask (and, this is by no means an exhaustive or complete list) could include:
- Who exactly (individual names) will need permissions to change things on the site?
- What specific things/features/content should each person have permission to modify?
- On your contact request form, what kinds of information do you want to request from the submitter?
- Do most of your customers surf the web from a computer or from a phone or tablet?
- What is the target demographic or your intended audience?
The list I use is actually around thirty questions, but it varies by the nature of each engagement. Other topics include search features, SEO, advertisements, visitor tracking, types of content, mapping and charting, multimedia and streaming, and more. The point isn't that you try to ask every possible question, but to ask every possible RELEVANT question pertaining to the task or project at hand.
Too Quick/Eager to Start Working
You might think this is a good thing, but in the context of providing a quality, comprehensive service to customers, a good professional will be patient (or, as patient as YOU are anyway). The most important step in the initial phase of a new engagement is gathering requirements. You might think that's boring or unimportant, but oh boy.Let me put this into a different context: A PRE-OP visit with a surgeon. You say something like "I want to lose weight. Quickly!". The doc says "No problem, I'll sedate you and get eighty pounds off of you in an hour.". You jump up and scream "Holy shit! When do we start!?". He grabs the scalpel and gas mask and asks you to lay back on the table. If you did that, you might wake up with both your legs amputated. Yes, you may have discarded eighty pounds, but that probably would NOT be what you had in mind.
You can smirk and think "yeah, well, that's a medical scenario, not a computer scenario." Here's what I'd say to that: If you woke up and found half of your business-critical systems no longer worked because you accepted a quick offer without reviewing the details and signing off on every single line item, well, how do you think you'd feel then? Somewhat like having your business legs amputated, probably. But, how would your boss feel about that? If you're self-employed it could be a catastrophic mistake. Yeah, you got your shiny new web application, but oops? Entering information from the new app seems to be wiping out information in your business-critical CRM database, and your most recent backup is missing a lot of recent changes. Dang!
Be specific. Be nit-picky. Be detailed and meticulous about what you want, and what you need (and do not ever confuse those two!). If you want rounded, magenta, 4px wide corners on the top banner of your application / web site, then spell it out. Better yet: provide an example. Draw it up in PowerPoint or draw it on paper and take a picture of it. Whatever. If you don't document exactly what you want, don't expect to get exactly what you want. Which brings us back to the part about Knowing What You Want.
No comments:
Post a Comment