Reference no: EM132902063

Writing an Executive Summary

An executive summary is usually required for Business, Engineering and Science reports or proposals.

It is a fully developed mini-version or overview of the Post Project Reviewso it is not merely an introduction.

An Executive Summary aims to:

• provide a brief overview of the whole report so that executives or managers could read the executive summary alone without the accompanying report.
• allow the reader to quickly understand the information contained in the report persuade the reader that the document is worthy of being read.
• provide concise, complete, specific and self-sufficient information that can be understood in isolation.
How to write an Executive Summary
Note: this is a general summary which refers to reports and plans of different types. Only use what is appropriate.
• Write the executive summary in your own words, using a formal writing style. Avoid using jargon.
• State the purpose/aim of the report. For example, the main purpose of this report is to......
• Describe the procedure that you used. The methodology or analytical process used to process the data collected.
• Provide the results of the study. The major findings may include a number of sentences.
• The recommendations (if applicable) should also be provided.
• Edit the summary to remove minor points; judgement is required to ensure that the summary is concise.
• Remove unnecessary words and sentences. Check accuracy of grammar, spelling, sentence and paragraph structures.
• Use formatting and graphics to highlight the message. Clarity of the summary can be improved through usage of bullet points and subtitles in the organisational structure. This will also make it easier for the reader to skim read.

Process involved in writing an Executive Summary
• The executive summary should be no more than a page in length and should provide an adequate representation of the entire document in a shortened form.
• The executive summary is provided on a separate page at the beginning of the report before the Table of Contents.
• An impersonal writing style is used so as to ensure that the report remains formal especially if the audience is your manager or supervisor.
• At least one sentence is provided for each main section of the report
• The key points in the executive summary should be presented in the identical order as they appear in the report so as to encourage logical flow and cohesion.
• It may be useful to write the executive summary after you have written the whole report so that it more accurately reflects the content of the report.
• Avoid recycling sentences or paragraphs from the body of the report as this can be repetitious for the reader.

Title: Insert the Project Title Here

Introduction
Instructions: This section is designed to tell the reader what the Post Project Review is about and to provide a guide to the remaining sections. Tell the reader the structure and what is in the Post Project Review. It should provide contextual information, that is, relate to the project and the progress you made.

Again, this is an introduction to the documentand should only provide broad details. Use words like "The purpose of this document is to report on...." and then "This document covers ..."
Project Background and Justification
Instructions: This section is a combination of the background to the project and its justification.

Start by providing a broad overview of the business and what they do. It does not have to be all that long, however, make sure you set the context for the problem.

Next, outline the problem or opportunity that the organisation had and thus the reasons for the project.

While it is possible for you to use some of the material from the backgroundsection from the original project plan, remember to be clear about why this project was undertaken. Your focus should be on describing the problem that the business needed to solve (or opportunity to exploit).

Project Objectives
Instructions: Clearly outline the objectives of the project.

By now you should know that objectives are not scope. In addition, objectives need to be SMART and have guided what you created. If you have produced something that is unlikely to fulfil those objectives, then you have produced the wrong system.

Remember, these are the outcomes of the project not what you produced.
Planned Minimum Viable Product
Instructions: Right from the beginning we emphasised that you had to identify all the work that needed to be done. It set the boundary between what you were expected to do and not do.

You should outline the initial Minimum Viable Product which was in the project plan. Remember, scope is not just features or components of the system. You had to do a lot more. Again, outline what was originally proposed in scope, that is, what work you expected to do and, if appropriate, the standard that was set (that is, quality)
.
Summary of Changes to the MVP
Instructions: It is not unusual that the MVP will change, in fact, in an Agile environment with a client focus, change is expected. That said, there is a difference between minor changes to satisfy client requirements, and major changes to scope due to some significatn issue(s). Every project will have some variation albeit small

Start with an outline of the changes to the scope of this project and the reasons for the changes.

Examine such things as:
• How the MVP changed over the life of the project - both more functions or less functions
• How scope change impacted on the project, that is, explain the effect that any approved changes had on the work required and on the Project Plan.

Outline any things that were expected to be done but were not. Outline any unexpected factors.

You may have done a basic risk assessment or at least had some idea of the problems that might have existed from the very start.
• Did they impact?
• Were there any risks or problems which you felt you could have identified earlier on in the project.
• What do you feel prevented you from identifying them, or were they unavoidable and unpredictable?
• What caused it? - your inexperience, communications, client management and so on. This will include requirements, additional work and changes to quality or standards.

Work Completed - The Final MVP
Instructions: This is a major section in any Post Project Review. It should outline what you completed in the project. How you show what you have done will vary according to the project. It may include screen shots, diagrams, tables and so on to support your outline of the work done. Don't just put in heaps of screen shots. Put in significant features or components and explain them. Don't overdo it!

Focus on the major features, functions or aspects of the system that you completed

You may wish to put in additional things in an appendix at the end of this document. Again, don't overdo it!

Lessons Learned and Recommendations
Note: the content of thissection is like a self-reflection but for a group not an individual. Your team should brainstorm on lessons learned to come up with some agreed points.

Instructions: This too is a vital part of any closing Post Project Review in a project. Although the Post Project Review is used to outline what was done, it is also used to document lessons learned in order to help an organisation with the management of future projects. However, we want you to reflect back on the year-long experience and, with that in mind, outline what you learnt from your experience.

Summarise the lessons learnt during the project, what went well and what you would do differently next time. Think about the project's successes (and failures), the areas which you think need to change and outline recommendations you would make for future projects in this area or for students in general. Ask yourself:
• What parts of the project went well? Not so well?
• What do you think could be better?
• How would you do the development differently?
• Were there any barriers to success?
• What techniques and approaches worked and what techniques and approaches didn't work
• What steps would you advise members of a similar project to undertake in the future.
Remember to cover both technical competencies (that is your technical skills), project management knowledge and skills, as well as your professional-ready (job ready) skills. The final ones relate to the Graduate Attributes such as oral & written communication, research skills and so on.

You might even like to make recommendations about the subject, its structure and content.
• How was it working in a group?
• What problems/benefits did COVID-19 restrictions create for the project
• As you know you used an agile/scrum or sprint-based development and reporting methodology this semester. The project was broken into a series of two week sprints. You were to develop products (or deliverables) at each stage. What did you think of this? Did it help with group work?
• Has your experience in these subjects helped you with your technical knowledge, project management and/or professional skills?

Attachment:- Project Report Template.rar