It’s Not Your Fault – You Don’t Know What You Don’t Know

Recently I was hired to rescue a website project that was almost two years late and was not making any progress. It was close to being ready (or so I thought). My job was to come in as the Project Manager, triage the patient, right the ship and launch the site. Working on this project reminded me of why I am writing my book, “You Don’t Know What You Don’t Know – An Entrepreneur’s Guide to What You Don’t Know about Building an Application.” This was a clear case of “You don’t know what you don’t know.”

Pie Chart Showing What You Don't Know

My client (like most small business owners) did not know there were several red flag with the project. It wasn’t her fault, how was she supposed to know? She hired professionals, and they are expected to do a professional job, right? If you have ever built a house, you know corners get cut. Things go wrong; this is why we have building inspectors. They are there to protect you, the customer. They keep the builders (somewhat) honest. General contractors, keep the subcontractors honest. There are checks and balances in the process. Where are the checks and balances for small business owners who are building a website or an application? Who is the “Building Inspector”? Who is looking out for their interests?

If this scenario sounds familiar or, you can see yourself in this situation, here are a few things to think about to help you be your own “Building Inspector.”

  1. Beware of a proposal that seems to go to be true. (It probably is.) Try to get a few proposals. See if the prices are in the same ballpark. If one seem low, that should be a red flag that the developer is underbidding. You might think this is a good thing, but it’s not. He will either charge you extra for things he forgot, or lose his shirt on the deal and maybe even walk away. You want to pay a fair price for fair work. If you only get one bid, ask a few business friends if they think it’s a reasonable price. Odds are you know someone who probably has enough knowledge to do the “sniff test.”
  2. Beware of a proposal that only outlines high-level functionality and does not provide detailed requirements. The more detailed the requirements, the more confidence that you can have in the estimate as well as confidence the developer understands the project. Just like building a house, you wouldn’t sign a contract to build a four bedroom, three bathroom house without specifics such as the size of the rooms, whether it’s a one-story or a two-story house, flooring options, counter tops, appliances, etc. If you did, you might end up with a house that has a kitchen in the master bathroom and three bedrooms that only your cat can sleep in. You wouldn’t sign an agreement without seeing a blueprint of the house, and you shouldn’t sign an agreement to build your website without the same detailed plan. This is why we require a Roadmapping sessions before each project, this is the blueprint for your website or application. Don’t be afraid to get into the details. The more details, in the beginning, the less chance for mistake and interpretation.
  3. Ask the developer how they keep track of tasks and issues. Email might seem like the easy and best way, but it’s not. It’s easy to lose ideas and feedback in an email. How many times has an email started on one topic and three emails later the topic has totally changed? This makes it hard to keep track of issues. An issue tracking system/project management system might seem heavy-handed and a pain to use in the beginning, but it will save time and money, over the project (at least ten fold!)
    Ask the developer what she does for testing? Does she write tests as part of her process? Does she test the code/site before handing it off? What is your role in the testing process?
  4. If software licenses/plugins are needed, who purchases them and who owns the licenses? As the owner of the site, you want to own the licenses. You should be the one to purchase the software, and the accounts should be in your name. You should have a record of all license keys etc. This way if you part ways with the developer you don’t need to purchase the licenses again.
  5. If your website or project requires custom development, ask who owns the code. Make sure you either own the code or have the rights to use, modify, change etc.
  6. Find out what the development process is, does the developer use a staging server, or does he make changes directly on the production server. If he develops right on the production server (your live website) walk away. Can you imagine what it would be like if he makes a small change to your e-commerce site and it goes down? It might take him hours to debug and fix.
  7. Where will the website be hosted? You don’t want your mission critical website to be hosted in the basement of the developer. You want it to be hosted with a hosting company that provides 24×7 support.

This is just a short list of things to “know”, it would take an entire book to cover it all. Hey, that’s great since I am writing that book. If you want to be notified when the book is ready for prime time, sign up here.