Communicating the idea to the development team is an ongoing procedure; its foundation however, should be in written form. It doesn't matter if you are outsourcing or having your development done in-house, writing the development documentation can be the most important development process. Development documentation should be written in the project planning stage, not only will this improve the communication between project management and the development team, it will also assist in the planning stages, uncovering issues which may have been missed that could have the potential to slow down development.
Some companies use templates in order to provide a development team with written information and this is a good solution for smaller projects such as banners or small programming changes. Such templates can also serve as a foundation for the documentation for larger projects. Technical documentation needs to contain certain elements, depending on the project of course. It, for example, needs to define specifications, needed texts, example URLs, and any other such information data.
Keeping the documentation informative yet simple can be difficult. The cover page should be left fairly plain, including such things as company name and the author name(s) with their contact information. Every time the document is edited, it should receive a unique version number. Version numbers do not have to be consecutive numbers; they nearly need to communicate the state of the document when compared to other versions. Don't forget the index, so the reader can navigate more easily and efficiently.
In the following pages all other information about the project and its development should be laid out. This should be detailed and include things such as who the target audience is, loading speeds, operating system, colors and database structure. This is the crucial information which will make the difference between improving development or being a waste of resources. While good documentation will speed up and improve development, bad documentation can do the opposite.
Although getting started with a clear vision is important, the most important part of development are deadlines for each development stage. Most small and mid-sized companies do not set deadlines. Those who do, set one deadline, although this shows a good effort, it is unlikely, depending on the project size, that one deadline is enough. The documentation should break the development process down into different stages, with their own deadlines.
Rewarding your development team for meeting deadlines may be a solution to move development along as planned. Rewards do not need to be large, but simply a small "thank you." If you choose to reward success with bonuses or other rewards for deadlines, make sure to add it to the development documentation.
Make sure to write a project summary after completion of the product. It should include issues that came up and how they were resolved. File away the project summary together with the development documentation and project overview. It will serve as a good reference and may help you learn and grow with your organization and its projects.
