And Finally, the Beginning
The beginning of the document is the last item to be written. To write it in advance is to put the recommendations before the investigation, and the summary before the facts to be summarized.
Of importance: the beginning of a project document is an executive summary. It is not an introduction or preface. It should not present background information or attempt to "lure" the reader into going through the rest of the document.
The executive summary should "work" as a stand-alone document. For many readers, it will be the only information they read, and the rest of the document is reference that can be reviewed if the reader wants more information. Ideally, you can remove it from the document and it will stand alone (this is often done, and named a "vision and scope" document).
Some have attempted to provide guidance as to the appropriate length and content of the summary, but it depends on the size of the project. A complex project cannot be summarized in a single page, and if you have no "general considerations" there is no need to fabricate some to include a section your summary does not need.
With that in mind, the author continues to document some of the sections a summary might contain, if they are necessary to the interests of the reader and appropriate to the nature of the project.
Recommendations
The recommendations are the heart of the document: everything that has been done in research and planning has the goal of presenting a recommended solution. If the recommendation is not compelling, the project will not be funded.
Recommendations are compelling because they do something for the company. A project may accomplish a myriad of goals, so you will need to whittle a list to the most compelling, and ideally not more than ten items.
Vague recommendations are not compelling, but "vagueness" is a careful balance between providing enough details to have credibility, but not so many that the details overwhelm the benefit you're trying to sell.
Since the primary audience of the executive summary is an executive, be brief and to the point, avoid technical jargon, and promote the benefit to the company in plain and concrete terms. The author recommends a list of "bullet points" rather than long text passages.
A High-Level Diagram
A high-level diagram of the proposed system may be more useful than a text explanation of what the system intends to do - but again, an illustration isn't automatically understood (repeat some of the advice from the chapter on that topic)
Problem-Solving Approach
When a project seeks to solve a specific problem, it is useful to address that directly: describe the problem in detail (the reason the problem is perceived to be a problem at all) and explain how the proposed solution addresses the problem. (The author provides an extended example).
Requirements Process
A brief statement that describes the process by which the plan was created can give credibility to the document. If the project team is large, present a summary (e.g., a team comprised of key stakeholders from IT, sales, marketing, and senior management) and add a list of names in the appendices.
General Considerations
This section, sometimes called "Caveats," presents potential issues, risks, and dependencies. Its purpose is to demonstrate that you have considered various aspects and are aware of possible obstacles to success. Disclose any caveats, but do not dwell on them.
EN: This seems political to me - setting up straw men. My experience is that naysayers will find their own reasons to bash your project, and you need not feed them. The detail in the requirements should imply the possible shortcomings (if a requirement or condition is not met, then the project will not achieve optimal outcome).
Scope
A statement of scope defines what will be included in the project. Sometimes, it will also indicate items that are specifically not included, but often that is evident by their omission from the scope. Scope has become a concern due to the tendency of projects to snowball, taking on additional problems that are related to their purpose, and exceeding budgets and timelines as a result.
A scope statement is your defense against attempts to piggyback tasks onto your project, or to deal with assumptions about what is included. While the scope may change, it's generally understood and accepted that a change in scope will change the budget, timeline, and even goals of the entire project.
Other Potential Sections
The author lists a handful of "other sections" that are sometimes included in an executive summary - but states "don't include any of them without a specific reason or meaningful content." The problem with rigid adherence to templates is that if you mock up some content just to have a section included, it will not be supported by the content of the proposal, and you'll end up undermining yourself.