| I'm afraid not. The best I can do right now is offer an example outline of what I do. That said, if I'm working with a good project manager my format will differ: I'll focus a lot more on the technical details and leave all organizational aspects out (e.g. timelines, dependencies and impact on other teams, etc). The key principle is that anyone (sales, marketing, support, product, etc) should be able to benefit from reading it and find it intuitive to see where you're getting into the technical details and skip ahead to the next major point. 1. Overview A paragraph of two explaining the what and why of the project. Maybe some links to other related key documentation. Don't put anything technical here. 2. Change Log Bullet-point list of dates and major changes. Think of it like a git commit history. 3. Scope What systems are affected? Are there phases to the project to be called out? If its principally one system/repo/etc in question, what major components are changing? 4. Requirements/Tasks (the main body) Use a numbered list and aggressively refactor as you go so high-level items rise to the "left" and all related details are broken out as sub-lists. You can loosely think of it as something like "[section] > [epic] > [task], [task], [task]". Prioritize the list based on dependencies so you're always referring back to already-mentioned requirements instead of yet-to-be defined things. 5. Supporting Docs Put long-form examples, scenarios, diagrams, etc in their own section. Some people will only care about these, especially if they provide integration examples. 6. Concerns and Questions Ideally by the time a first draft is done this section no longer exists, but usually you'll find that you need to do research or get feedback from others to finalize the whole thing. |