Good Planning is critical to the success of any project. Start off a project by creating a simple purpose statement. This is just a one sentence description of the problem that needs to be solved. An example would be something like this:
“Our website will engage visitors to learn about the products we sell through great content and images, and ensure an easy purchase through our secure shopping cart.”
Just like submitting a screenplay to movie producers, you have to produce a one-sentence description summarizing the plot of the script.
Once you get a concise idea of what it is you are going to develop, you can then write a program specification (or spec) which is very detailed. It forces you to think through a project from start to finish before you write a single line of code. This is where you interview anyone with an opinion about the project happens. Requiring your customer or employer to review and approve your spec before you start writing code will help to avoid errors, misunderstandings, and conflicts down the line. It might include the history and what problems the program is intended to fix, what existing processes are being replaced (if any), what the program is expected to accomplish, and what benefits the new program will bring.
The program spec goes further in detail with important assumptions about the project, including the languages it will be written in, who will be the audience, what level of security is needed, who will be using the program, and perhaps what components might be divided up and to whom. Of course, depending on the size of the project, it can be a few paragraphs or many pages.
The requirements part of the spec is the most important. This is the painstaking, step-by-step detailed explanation of how the program will work and what it will look like. What is the overall feel, look and objective of the company? What will the user be presented with and what will they need to provide, what information will they get, how the input is transformed to the output, how the information will be stored, how it will be retrieved, and what to do if there are problems. This is also where you nail down imagery, font choice, color scheme, and layout. List the information you need and the feedback you require and interview those individuals who will be giving the feedback. Nailing down the design and function details is critical. You don’t want this part of the process to drag on – which it can – but changes to the design or layout after you’ve started developing can become very problematic.
The importance of a detailed spec is what will determine the timeline and cost. Depending on the project, you may need to set milestones. Milestones are dates that you expect major pieces of the program to fall into place. Give yourself plenty of leeway because things might not work out as expected, which can often be the case. Milestones are great because they help the developer plan his/her work and monitor the timeline. This can help with documenting any further changes beyond the agreed upon spec. Unforeseen changes will affect the timeline and the overall cost of development. This is a vital component for designers, developers or programmers. Changes made to the agreed upon spec are fine as long as they are approved or there is appropriate compensation for changes affecting your scheduled timeline. It is paramount that everyone with an opinion agrees to and understands the purpose of the spec and the timeline. If you are a freelancer or contractor and find yourself in a position where a project is going longer than anticipated or agreed to without compensation, this can spell disaster. This is serious business and your time and effort shouldn’t be dismissed.
You need to be thorough and keep your explanations simple and clear. There is no right or wrong way to write a spec. You are creating a blueprint that you and someone else can understand and work from. Don’t leave anything open to misinterpretation. Use graphics, illustrations, tables (wireframes) to clarify the details because you really don’t want to be derailed in the middle of the project after you’ve started writing the code.
An important thing to remember – your client or employer expects you to do the job you were hired for, and you expect them to trust your judgment and ability to do the agreed upon project as stated in the spec and timeline. Any changes to the spec are pretty big issues and shouldn’t be taken lightly. Respect is a two-way street.
If you write an accurate, detailed, and easy to understand program, application or design spec that your employer or client approves, your project will just about write itself. Happy coding!