In trying to figure out my first blog post, I thought to go ahead and start at the beginning of web and application development. Which is the discovery phase.

After doing dozens upon dozens of projects in my time and now moving more on the sales side, I kind of lost sight of those whom are not normally close to development. It starts with a phone call with a prospective new client. He is already annoyed with people giving him the run around, budgets coming in all over the place and finishes up his frustration, “What the hell is up with this discovery phase?”

My opinion is that the vast majority of ANY project requires some sort of a discovery phase. It’s all in the manner of the nature, size, and complexity of the project. Also, new and existing clients could alter metrics. Naturally the larger the project the larger a discovery phase should be made. Regardless whether this is being billed or non-billed time, a discovery phase can dramatically increase your chances and almost ensure a successful project.

Please understand that a discovery phase is not just about learning everything about your business then stealing your secrets and first born children. We honestly could not care about that. Believe it or not, we WANT you to succeed.  Your success is our success. We like to build things that see the light of day and then we are crazy proud to say we built that. Quite simply I try to accomplish these tasks in a discovery phase:

• Educate ourselves about your business and your customers
• Educate you to make sure you are understanding what you are asking
• We like to get a glimpse of your character and corporate culture.
• We love to get an idea of the future.
• Make sure we completely understand every task and milestone of the project.

EDUCATE OURSELVES

We want to know as much that is relevant to the project about your business and customers as possible. Any good developer should want to make sure that what is important to you is also important to them. No superiority complexes, developers (or project managers) should shut up and listen for a very long time and suck up as much as possible.  The more we know of things you like and dislike in general business, as well as development, the more we can prepare ourselves to avoid those uncomfortable situations, generally speaking. You may actually indicate trouble you are having with a certain situation that we could present a fairly simple technological resolution.

EDUCATE YOU

After doing all the listening and hopefully learning a ton, it is now time to reciprocate. Your developer should be giving a supportive or constructive response.  It’s always great to get outside opinions on things. Why not get an opinion from someone whom is paid to think with a very logical, analytical, creative and hopefully modular process. After the general business discussion, we should be educating you more on the details on the nature of the task and how we accomplish what we do. Knowledge is power and quite often we as developers always run into situations where a client would say I did not know that. The more we teach our clients, the smarter our tasks get and the less explaining or confusion happens down the road.  This is a great time when you can explain why Facebook can do certain things and your website whom has not seen the light of day cannot. Also we can introduce to you certain ways of building things and features that can improve the product down the road.

CHARACTER AND CORPORATE CULTURE

Just like anything else there is more than one way to skin a cat. Depending how much you like to contribute to the current and future tasks could actually indicate on how to build things. Your view points on technology, how often you invest into your development projects, documentation requirements, what your existing team already knows, and so on. Small example, if your existing team loves using LESS for style sheets rather than SASS a developer could accommodate and save you the learning curve of your existing employees. May not be the best example but there are plenty of other server side languages, package handlers, database handling, cdn’s  and other services and languages that could be influenced based on what you already used.  Not everything is completely negotiable but there are ways to simplify and adjust for what your employees like to work with.

IDEA OF THE FUTURE

With development frameworks being born every year  and design principles running ramped, developers in general are getting better (or should be) at building things with modularity and growth in mind. When we know what your future steps are after this initial project we may be able to keep those items in mind and proceed with structures of code and database structures that will not put you in a corner to accomplish your future projects. Believe it or not, some great developers are actually really bad at making structure/architectural decisions.  That is a whole article its self. I have a soap box to let out. 🙂

EVERY TASK EVERY MILESTONE

When rushing through anything the details can be lost. When working with large companies where information is passed down through multiple people, details can get lost. Even in the worst case where details are passed through in oral discussion you have to ensure everything is written down and placed in some kind of requirements document. Just in case, a requirements document is some kind of list of things (features/tasks) for the development company to perform and are required for the project to be considered complete. Talking over every task and milestone 2 or 3 times often births new ideas or features that were overlooked, over simplified and just straight up forgot.

So there you have it. These are my basic steps and thoughts to why any project should have some sort of a discovery phase. These phases can span a couple hours in discussion or it could be dozens of hours on larger projects. Hell it could be hundreds of hours for corporate and enterprise level projects. Either way they are needed and extremely useful in securing your fate at a successful project.  There are no absolutes in this discussion and feel free to include more subject matter if your project requires it, but not much should be taken away from the list unless it applicably is unwarranted. For example if you already have done projects with a particular company, then half of this can already be avoided. Some common sense has to be used.

Remember that the way a discovery phase is paid for or billed is flexible to the situation and company. If you cannot see the benefits of a discovery phase then any web design/development company may look at you crazy and potentially as a volatile client.  You have been warned. Happy building my friends. 🙂