- Getting Started Before You Get Started
- Establishing the Guidelines
- Timing is Everything
- Establishing the Right Team
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Establishing the Guidelines
Now that you've asked your client every possible question relevant to the project, it's still not time to start writing code. The next thing is to lay out your project roadmap. This is when you can use one of those project-management software applications (or if you're a techno whiz, write your own program). If you're not comfortable with that, break out pen and paper—but for God's sake, write stuff down. Start with writing a creative and technical brief. Take all that information you just received from your client during the "question-and-answer" period and write up a statement about what needs to be done. Write up the goals and objectives of the project, both creative needs as well as technical requirements. Just as important, write down the things that your client doesn't want. These creative and technical briefs will help keep you on track as you develop, especially the larger the scope of the project and the more time needed to complete this project. Another way this will help is if you have multiple people working on this project. Be it staff or freelancers, in-house personnel or outsourced resources, everyone will have the same directives in front of them. No one can say they weren't told.
Next, draw a schematic or flowchart of the site. It doesn't matter how you do this. I still use Quark Express to design my layouts. Any software that can create an organizational chart (whether automatically or manually) can be used. Be as detailed as possible. This serves many different purposes. First of all, this schematic is a great checklist to make sure that you've covered all of the areas that need to be developed. I recommend that once you have it complete, have your client sign off on it. Many clients may not understand it (again, they hiring you to develop the site because they are not developers, so you may need to hold their hands and explain the process of how the site will look and function from this line diagram). But once they sign off on this, it protects you from the client changing his mind every five minutes on what is expected in the site and where it belongs.
Most standard contracts that we write let a client know that if they change something once signed off on, it's going to cost them more money, take more time to develop, or possibly both. This will also help you plan your programming strategy by seeing how things link together and possibly avoid a lot of redundancy. You'll be amazed at how quickly the site makes sense to you (or doesn't make sense if it's a bad site conceptually) when you visualize the entire site on paper. But you're still not ready to begin programming.