We recently sparked some curiosity and discussion with an article detailing our website development process. Many of our readers asked us to go deeper into the specifics of parts two and three of that process which deal with the "Research & Discovery" and "Onboarding" phases we implement with each of our clients.

We're happy to help. Below you'll find our outline for learning what we need to fully understand a project and ensure we mitigate any possible misunderstandings between ourselves and our clients.

Feel free to adapt these for use in your own business.

Baseline Project and Client Information

This first batch of information collection may seem like a no-brainer, but we've missed some of these in the past which had a negative effect when planning the actual goals further on in the process. The idea is to start simple and keep expanding on previous discovery items to form a well-rounded view of your client and their business needs.

  • Clients Name
  • Project URL
  • Stockholders - people working on the project and their roles in the company.
  • A little history/background of the company and project.
  • Target Audience/Users

Vision of Problem

Every web and business development project includes a problem (or problems) that need to be solved. Identifying these issues from the perspective of the business owner and their customers is the only way to identify a true solution and a logical way forward for development. These should be agreed upon by both client and agency.

  • Problem Statements
  • Risks
  • Needs
  • What would be a failure?
  • Assumptions
  • Top Priorities

Vision of Solution

The first bullet point below will be the answer to the problem statement and top priority items above. By clearly outlining what a successful project includes, you create a definitive guideline that all other items on your list must follow. If something doesn't align with the definition of a successful project, it's likely just fluff and isn't necessary to include in the first place.

Just as important as outlining specific budgets, goals, and timelines is to define those items which are not included in the project. You know what they say about assuming. Well it can cause serious issues between a client and agency near the project completion date. Documenting agreed assumptions and things that are not included makes it very clear for both parties when a project is deemed complete.

  • What does a successful project look like.
  • Goals
  • Timeline
  • Any other important dates
  • Budget
  • Assumptions
  • What will not be delivered
  • Backlog/Other Phases of Work

A Little More on Documentation

Document as much as you can. This will help you later. Any little bits of info that don't quite line up with the above outline should be kept somewhere. This might be a list of current features that are to be ported over or very specific key items we need to make sure our entire team fully understands.

View Our Detailed Case Studies

If you haven't already, please read through a few of our case studies to see how we've applied the methods above. As always, if you have any questions or if you want to see what we can offer your business, feel free to get in touch.