Showing posts with label contracting. Show all posts
Showing posts with label contracting. Show all posts

Monday, April 18, 2011

Empowering

From what I can tell there are two basic kinds of IT consultants: Those that are fine with doing the work, and those that want to empower their customers to be more capable.  It's not always a clear distinction of course, and quite often it is driven by the customer relationship.  In most cases I try to empower my customers.  I don't mind getting billable hours, but I don't like doing the same fix for the same break over and over again either.  I'd rather fix it, show them why it broke and how to avoid breaking it, and hopefully they appreciate the intent enough to hire me back again.  So far, so good.  Before you think I'm patting myself on the back, don't.  There are a huge number of consultants and other service providers that do the same thing every day.  The next time you get to experience someone trying to help you be a better you, thank them.  Pay it forward too.

Thursday, August 26, 2010

Part 2–Contractual Mumbo-Jumbo

If you bothered to read "Part 1" of this, then I can go ahead and say that this article is "Part 2".  Amazing, isn't it?  No.  But here goes.

NOTE: Although this article, and the other parts to it, are focused on web development projects, most of this applies to all aspects of technical services.  Take from it what you like, ignore the rest.

So you've spent many a late night building this dream of yours: a web site.  You've got your notes, sketches, templates, facts and figures, budget plans, timelines, and maybe even drawn up a business plan (or business case, etc.).  Maybe you've built a prototype or two in WordPress, Ning, SquareSpace or KickApps, and some of them do things the way you like, some do not.  Maybe one of them is 95 percent of what you want, but you can't figure out the last 5 percent.  No problem.

Now you're ready to meet with a web developer (or five or six).  If you feel that your idea and your plans are sensitive enough to protect from someone else stealing them, you probably should consider getting some basic protection in place.  By that, I mean legal matters.  This doesn't have to cost you anything except a little time.  If you have a friend who is an attorney, by all means ask them for advice.  If you're not fortunate (or unfortunate) enough to know an attorney, fear not, there are free options available.

Non-Disclosure Agreements

A Non-Disclosure Agreement, or "NDA", is a document that states that all parties (legal term for all persons who agree to the document by signing it) must abide by the terms it provides.  Those terms are usually focused around limiting what the involved parties can say about the project, or certain aspects related to it, to other people.  There may be penalties stated for breaking the terms. There may be time limits and other special conditions.  They can be vague and general, or particular and specialized.  The terms can be tailored to suit your needs, and the concerns of all others involved.

Regardless, the purpose of the NDA is to prevent people from blabbering, stealing, sharing your sensitive ideas and planning.  They often go both ways as well.  In many cases, the NDA will also protect the other party against you telling other potential bidders about how they estimate projects, or what resources they can leverage, and so on.  It protects ideas, capabilities, goals, and material works as well.  There are plenty of free NDA templates available on the Internet for you to download and modify to suit your needs.  You can also consult an attorney, which is usually a better option if you can afford it.

Before you sit down to discuss your ideas with developers, even for preliminary estimates, don't forget to decide whether an NDA is worth including.  Have them sign it before you discuss your project.  They may want some time to review it before signing it, which is always a good idea.  The goal is to protect your idea.  But make sure you really need it before you spend a lot of time on it.

TIP: Search the web for "non disclosure agreement template" for links to sites with free and low-cost templates to get started with.

Statement of Work

A Statement of Work, or "SOW" is a shopping list of what the developer will provide to you as part of your agreement.  It should include an itemized list of each and every task, key dates or time frames, milestone terms, materials to be delivered (source and/or final), and so on.  They should be detailed.

Don't just say "develop customer registration page".  The item should either describe what that page will look like, what it will do (functionally), and even refer to figures (sketches) or screen shots.  Describe workflows as well.  Write down the workflow process for things like registrations, subscriptions to mailing lists, unsubscribing, opting out, privacy agreements, and so on.   A good web developer can help you work this out, but you should understand it fully so you don't feel confused and frustrated later on.

Most arguments and disagreements I've seen were born out of vaguely worded SOW's.  It's amazing that some customers actually get frustrated when I ask questions to help nail down the details.  They assume that by discussing and agreeing "now" will be understood the same context six months later. "I thought you said…" or "I thought that meant…" are common phrases that indicate someone is confused and upset.  They feel let down.  They feel cheated.  That's not good for business.

Nail down everything early on.  Shapes.  Colors.  Fonts.  Pages.  Graphics.  Workflows.  Titles and sub-titles.  Table borders.  Margins.  Footers.  Get the specifics and put them into the SOW.

Here's how I look at a SOW: Think of it as though you were asking someone for instructions on how to build the site, and then you were going to hand it to a complete stranger with no knowledge about the project beforehand.  Will the SOW have enough detail to guide them to build it properly?

TIP: If the developer doesn't insist on specifics, or gets irritated by your insistence, walk way and find another developer.

Service Agreement

A Service Agreement is simply another name for a contract.  It's a written agreement that states who is doing what for whom.  It also states conditions, limitations, liabilities, responsibilities, exclusions, warranties, assumptions and expectations, important dates, deliverable items, ownership issues, copyright and trademark issues, legal jurisdiction, arbitration terms, invoicing and payments and so on.  Lot's of legal mumbo-jumbo, but it's good.  Yes, it is GOOD.  It protects YOU.  It protects THEM also.

While there are plenty of free contract templates available on the Internet and at retail stores (yes, they too have them for sale), this is one piece of the puzzle that I always recommend getting from a qualified attorney.  They shouldn't charge a lot for this if they're reasonable.  If you know an attorney, ask them what their fees are for either drawing up an agreement or reviewing an agreement you draft on your own.  Make sure they are familiar with service agreements involving consulting or technical services.  An attorney that only works with building contractors or retail contracts is not a good choice unless you can't find anyone else.

This is part one of the Agreement preparation.  Next…

Next, you will give it to the developer/consultant for them to review.  This is still considered a draft at this point.  They will likely want to take to their attorney to have it reviewed and they may request some modifications as well.  That's normal.  It's why we have attorneys.  They look things over and catch the loopholes we don't see, and plug them to protect us.  It's a good thing.

A reputable web developer will often have a prepared agreement from previous projects which has been reviewed many times and should be fairly good.  Always ask how many times that same agreement has been used in the past.  The more the better.  But even so, have it reviewed by your attorney to make sure it fits YOUR needs as well.

TIP: Consult an Attorney when developing a Service Agreement.  If the developer provides the Agreement, have it reviewed before signing it.

Invoicing

Your Service Agreement should include instructions on how and when invoices will be submitted, how they will be paid and how long it should take to process them.  It should also describe how to resolve discrepancies between delivered services/materials and invoiced claims.  There are two kinds of invoices in my book: Intermediate and Final.

An Intermediate Invoice is one that is submitted for partial delivery of items requested on the SOW.  There may be multiple such invoices before the project is completed.

A Final Invoice is just that: Final.  Some projects will only require a final invoice.  Some will involve intermediate invoices. Some will involve both.  It typically varies by how large, and complex the project is.  It can also vary by how the customer handles invoicing (that would be you, in this case).

A Final Invoice can just state something simple like "services and deliverables as requested by SOW ___" and an associated amount requested for payment.

An Intermediate Invoice should always be more detailed.  It should describe EXACTLY what tasks were performed.  It can break them apart with sub-totalled amounts, or just itemize the tasks and provide a total amount.  That is something you should discuss with the developer AHEAD of beginning work on the project.

TIP: Ask for a sample invoice so you don't get caught by surprise.

Summary

I hope this helps.  It may seem scarry, but it's really not.  These are important aspects of getting involved in any project that requires hiring someone else to do work for you.  If the work involves something sensitive or precious to you, it's worth protecting.  It's worth protecting at the beginning, in the middle and at the end as well.  Don't rush through it, and don't let anyone rush you either.

So You Want to Hire a Web Developer?

I've been doing web development work for quite a few years and have compiled a list of the top things customers should do BEFORE they go looking for a web developer.  I mean BEFORE. As in BEFORE you even talk to one of them.  BEFORE you email or IM or strike up conversation at a party with one of them.  This is PART 1 of more to come.

Things to Do:

  1. Do Your Homework
  2. Decide What Exactly you Want Your Web Site to Do
  3. Determine How Much You Are Willing to Spend
  4. Determine How Much Time You Can and WILL Devote to Running the Site
  5. What is the Business Plan?

Things to Avoid Until Later in the Planning:

  1. Search Engine Bullshit
  2. Ads and Advertisement Sales
  3. Selling Stuff and Shopping Carts

Do Your Homework

What other web sites will you be competing with?  Don't you DARE say "None!  I have a unique idea!"  Bullshit!  There are no more unique ideas on the Internet.  Innovation is dead.  You have to find a niche and exploit it.  Even if it's very close to someone else's niche, figure out (exactly) how and what you can do different and (more importantly) BETTER.

Decide What Exactly you Want Your Web Site to Do

If you can't describe what your site will do in one short sentence, you have no direction or idea what you're doing.  Narrow it down.  Focus.  "I'm going to sell stuff" is a start.  Sell what?  To whom?  Where?  How?  Do you have the means to handle packing, shipping, order tracking, returns and customer support?  "I'm going to start a ___ community."  For whom?  Why?  Why would they drop the other sites to use yours?  You have to ask the hard questions up front to avoid dumping an enormous amount of money and time into a bad idea.

Determine How Much You Are Willing to Spend

If you can't invest more than a few hundred bucks in this idea, it's probably going to have to take the low road for phase 1.  Maybe rely on a canned, do-it-yourself path like WordPress, KickApps, Ning or whatever.  Whatever you do, do not just run out and buy a domain and hosting plan before you know what you're getting into.  It may end up bleeding you dry and you won't have enough left over to hire someone to help you dig your way out (and up).

Determine How Much Time You Can and WILL Devote to Running the Site

Almost everyone I sit down with to discuss helping them bring their ideas to life overlooks this key aspect.  I really don't understand why this is.  Standing up a web site is the START of the dream, not the end of it.  To me, this is like practicing for years to get drafted into the major leagues, only to get up for the first at-bat and then say "you mean I have to actually hit a ball now?!" (yes.  you do.)

Ask any person that owns their own business how much time they devote to it, especially during the first year.  They will almost always tell you 24x7.  Making a web site work is no different.  You can't casually throw it out there and expect it to draw in tons of followers.  If you have brand recognition already, then maybe you can.  But if you're starting from square one, you will need to make this project (your dream web site) priority #1 for at least a few months.  If after six months of serious effort and labor invested into this you don't see results, re-evaluate and adjust.

So, Now What? : Step 2 / Compiling Your Ideas

If you've already done all this homework and have your idea honed and you're still pumped and excited, there's still more planning and preparation to do.  This will save you a BIG ASS amount of wasted time and money hashing things out with a developer.

Sketch Out Your Ideas – Get a pad of graph paper (yes, you remember that stuff from Geometry class, don't you?).  Use a pencil and sketch out the rough layout of your imaginary web site home page.  Figure out where the navigation links will go.  Horizontal?  Vertical?  Static or dynamic?  Top or Bottom? Left or Right?  Somewhere unusual or diagonal?  Flash or HTML5 animation?  Keep in mind your budget limits.  The more fancy your animation and graphic, the more time and cost.  It will grow fast.

Suggestion: Keep it simple for the first phase.  Don't get mired down in animation crap.  Focus on making the idea work.  If the idea is selling a product or a service, and you waste all your time and money on dynamic whiz-bang menu graphics, you will almost certainly fuck up the main goal of your site because you're getting distracted.  Build the function first.  Then make it pretty.

Do users have to sign up?  Do you need to protect privacy?  Have you checked on the legal issues?  Will there be any minors using your site?  Just adults?  Will you need to support multiple languages?  Will you need to sell something in multiple currencies?  If there's a discussion forum, who will moderate the comments and keep the kids playing nice in the chat groups?  If there's a blog, who will be posting to it and how often?  A blog that gets updated once a year gets ignored.

After you scratch together all these ideas and concerns, stop and ask the questions again:  Why is this different?  What makes it different?  Why will this work better than other sites?  Who are my biggest competitors?  What are they doing?

Step 3 / Finding The Right Tools

So, all that's done and you have a pile of sketches and clips and prints, and you have notes and you know what you're aiming for.  The next step is finding a web developer.

Stop.

Do you really need one?  Did you really look at WordPress?  Did you check out SquareSpace, KickApps and Ning?  If not, do it now.  And you better take at least a full day (if not several) to really dig into them and use their free trial services to feel them out.

If WordPress is what you like, now you can focus your search on a web developer that has experience with customizing WordPress sites and plug-ins.  Same goes for KickApps, SquareSpace, Ning or whatever.  The main point here is that you may not need to build a web site completely from scratch.  If you have zero experience building one that way, it might be best to consider one of these other options instead.

But if you decide you really need to build your site from scratch, or maybe you have someone that knows how to build sites from scratch, you still need to keep your ideas focused and guided.  Nail everything down as much as you can early on.  The more you change things during the building phase, the more delays you will cause, which equates to more cost and frustration.  You may think it's great to change the shapes from squares to ovals, or the colors from purples to blues, or change the text fonts and sizes, but the developer is going to run out of patience eventually.  Remember that this is YOUR dream.  For the developer it's a project.  A job.

Summary

I have no intention of shooting down your dreams of building a wonderful web site.  But so many people come to me without having thought through their ideas.  If you can't hone and optimize your ideas, how can anyone else?  Especially a complete stranger.  You need to do some homework and piece your idea together.  You will amass a pile of crumpled paper and break some pencils.  You will fill folders with scratched ideas drawn up in Microsoft PowerPoint, Paint, PhotoShop, Visio, and just about any application you doodle with.  You will give up and start over.  Again and again.  But if you have a good idea and it survives your own research and planning, chances are it's worth pursuing.  But don't sit down with a web developer until you know what you want.  It will save you a lot of frustration and keep your costs and expectations reasonable.

Monday, September 8, 2008

The Perils of Web Development Projects

During my involuntary time off from a normal day job (back in May-June), I pushed harder into my web development background to make ends meet. I bought a business license and stood up my web site and began marketing my services, along with 300,000,000 other web developers. The problems I ran into were the expected ones, but that's been par for the course and things have picked up a little anyway. I can't quit my current day job but it helps avoid foreclosure and keeps food on the table.

I was a bit surprised however that one of the constant issues I've seen is with hosting services. That's right: hosting services. Many "customers" I work with aren't savvy when it comes to the technical background of standing up a web site. They just want it "done" and don't care about the messy details. The problem is that in that general haste, many (most) of them have just handed the keys to some developer in the past and expected them to park the car, wash and vacuum it and put a new air freshener in it, no questions asked.

My policy is that I do not provide hosting. I won't even buy hosting for the customer. I won't register a domain for a customer either. I will assist in every possible way, short of putting anything in MY name. I prefer to focus exclusively on developing the SITE, not what the site runs on. Not so with other developers it seems. They prefer to hold more control over the entire project, and often after delivery. Does this sometimes cause angst and confusion for customers? You betcha. But let me explain...

Each time I've met with a customer to do either a web site overhaul, or an enhancement, they've almost always had an existing web site (and domain) in operation. Then they engage me to do the work and almost instantly I run into access issues. These require me to either lean on the customer to act as the broker, or the customer empowers me to talk directly with the previous developer, to gain access to the existing host or content (or both usually). Talk about an emotionally awkward situation. "Hi, I'm the new developer guy. I'm calling to usurp your work and future earnings from this customer".

The net result is bad. Time delays, incomplete information, sometimes outright inability to get anything simply out of hostile reaction. When I see this happen, I simply point at it, and give them the usual "A-ha! See what I mean now?" Then they have the epiphany moment.

By putting the domain registration, and hosting plan, in the customer's name and under their sole control, it not only empowers them to do things with more agility, but it doesn't hold them hostage to an irate developer.

I had one customer that was going to court with a developer over access to their own web site. That dragged the host provider and attornies into the mix and things got stupid. Of course, nobody mentioned that until I asked about gaining access to the existing content in order to make the requested enhancements. A completely unnecessary waste of time and money, not to mention unnecessary stress.

So, the moral of the story is this: If you contract someone to do your web site (and I really don't care who you prefer, I'm not marketing myself here - believe it or not) if they prefer to do the domain registration and hosting enrollment: RUN! Find someone else! A good analogy would be something like paying a locksmith to change your house locks and he ends up holding the ONLY set of keys from then on. Bad.