Table 1: EduStream Project - Formal Meetings Listing

Meeting Schedules
Code	Short Name	Period (d/m/yy-d/m/yy)	Freq	Day	Mediums	Comments
PSG	Steering Group	1/04/24-24/06/24	W/2W	Tu, Th	F2F	EdMI team members only
PSG	Steering Group	24/06/24-19/07/24	2W	Mo, Fr	F2F,VC	All team members
PSG	Steering Group	19/07/24-9/08/24	F	We	F2F,VC
PSG	Steering Group	12/8/24-05/9/24	W	Mo	F2F,VC	Finalise strategic decision making on design
PSG	Steering Group	6/9/24-6/11/24	F	Mo	F2F,VC
PSG	Steering Group	06/11/24-31/12/24	W	Mo	F2F,VC,TC	Monitor system testing and Beta 1 Go Live before Christmas break.
PSG	Steering Group	06/01/25-16/05/25	W (F A/R)	Mo	F2F,VC,TC	Strategic planning for System testing, and Beta Testing strategic decisions & engagement of key stakeholders (including site personnel through TC as required (A/R)). Where meetings are not required, the tempo will be reduced to fortnightly over this period.
PSG	Steering Group	16/05/25 - 21/06/25	D (W A/R)	Th	F2F,VC,TC	Project Final Report Meeting Closure update meeting

Table 2 lists the formal reports that will be utilised to share key information within the EduStream project. The key reasons for implementing this reporting cycle are explained in the paragraphs below the table.

[Instructions for what to include in this table: Expand on and rationalise the example information provided in Table 2, by adding additional rows. When developing this table please give careful consideration to the following aspects:

Report > Meeting/Decision > Report cycle. It is important to ensure that the identified meetings and reports tie into each other. Therefore, identify key reports that will be required to feed information for decision making into each of the key meetings/decision points you outlined in Section 5.1. These reports should be provided to the meeting participants in enough time before the meeting, so they can read the material. Every meeting should then trigger the development and distribution of either a report or minutes. These products from the meetings need to be distributed appropriately to stakeholders so team participants know what is going on and what key decisions have been made. Additionally, they should normally be stored in the Knowledge Base, which will act as a form of distribution centre and archive. The following focus box provides some insights into matching the phasing defined in Table 1.

HOW TO HANDLE DIFFERENT TEMPOS FOR MEETINGS

In Table 1 you adjusted the intervals of meetings based on different decision making needs through the project lifecycle. This will obviously have implications for the reporting cycles as well. However, these changes are typically fairly easy to manage through the following strategies:

Strategy 1. The first strategy is outlined in the 'Putting them Together' slide within the Topic 8 Workshop. You will notice in this slide that the Steering Group meeting is conducted fortnightly rather than weekly, whereas the subordinate meetings (and their associated reports) are conducted weekly. This is not a problem. In practical terms, the way this works is as follows:

On weeks where the Steering Group meeting is being conducted, the synopsis elements of the Quality Group Weekly Project Update Report (QGWPUR) and Technical Development Group Weekly Project Update Report (TDGWPUR) are sent to the Project Manager (or their delegate). As explained in more detail below, these documents are integrated into the Steering Group Weekly Synopsis Report (SGWSR), which is used as a catalyst for decision making in the meeting. From this meeting, a Steering Group Weekly Project Update Report (SGWPUR) is created, which includes the summary of the outcomes from the meeting and copies of the underlying reports (e.g. QGWPUR & TDGWPUR, which are provided as appendices or links). Additionally, the synopsis information from the SGWPUR and some additional information/remarks required by the Chief Executive Officer (CEO) are promulgated in the CEO Weekly Project Summary (CEOWPS). Additionally, once a month, a very similar report to the CEOWPS is produced for the Board. This is the Board Monthly Project Summary (BMPS).

During the non-meeting weeks, the same QGWPUR and TDGWPUR reports are still sent to the Project Manager (or their delegate). Effectively, the same SGWSR report is developed, but this is simply distributed to the Project Steering Group members by email. Where actions are required in the non-meeting weeks these are coordinated by email or less formal versions of the Project Steering Group meeting. If no actions are required, an appropriate synopsis is added to the SGWSR by the Project Manager and this is promulgated as the SGWPUR. Once again, this synopsis information is then forwarded up the hierarchy as the CEOWPS and BMPS (as required). In other words, the same reporting approach is applied, even though the meeting is not implemented. This is one of the most commonly applied strategies that is implemented.

Strategy 2. The second option is to change the period of the reports. This aspect of setting the period covered by the report is explained below. Therefore, as shown in the preceding examples, these were all weekly reports. If the meeting schedule were set to fortnightly (e.g. the Steering Group meeting), the name of the report being developed in this meeting could be changed from the Steering Group Weekly Project Update Report (SGWPUR) to the Steering Group Fortnightly Project Update Report (SGFPUR). Alternately, when meetings are being conducted in a D, 2W or 3W cycle, you would often not need to send reports up through the hierarchy after every meeting. In these cases, the reports would only be promulgated once per week and would provide an appropriate synopsis of all of the preceding meetings/workshops during the week.

Please note that for this assignment, you will not need to change the tempos of the reports to align with the different meeting tempos listed in Table 1. Just apply the first strategy in this case.

To complete each of the report elements in Table 2, please apply the following approach:

Level of Reporting Required. In most organisations, you will find that extensive formal reporting is rationalised to help minimise workloads. For example, most reports are aggregations of subordinate reports with a short highlight synopsis provided on the covering sheets. In these cases, the cover report is one to two pages long and the subordinate reports are appendices or links (so the reader can drill down into the detailed reports within the Knowledge Base). This allows the reader to get a quick synopsis of the pertinent points and then drill down into important details if necessary (as these are provided within the subordinate reports). This recommended approach also helps to minimise work, as each level is typically just adding a one to two-page synopsis summary. Additionally, they higher you go in the hierarchy, the more likely it becomes that you might be able to automate Key Performance Indicator (KPI) reports to help minimise work. However, different organisations use different approaches, so you would need to follow their mandated reporting strategy. For the purpose of this section of the CP apply the general concepts discussed in the Topic 8 Workshop.

A USEFUL ADDITIONAL HINT

Don't forget about the relationship with the CEO and the Board. Typically, you would provide a strategic update/progress report to the Board/CEO prior to their monthly meeting (e.g. the BMPS discussed above). For the sake of this assignment consider that the Board meets on the first Thursday of every month.

If you consider this the endpoint of all of the reporting cycles each month, you can stage the preceding reports into a schedule that builds up information over the month. See the diagrams in the Topic 8 Workshop for more details.

To complete each of the report elements in Table 2, please apply the following approach:

Report Name. Place the report name into the left-hand column of the table. To make it easy to define the flow of the reports into and out of meetings, the conventions listed in the following focus box should be applied for this assignment (it also provides a useful model for you to use when you get out into the industry).

REPORT NAME CONVENTIONS

WG/Developer Title. For reports being generated by Working Groups, the Working Group's name can be included is in the short title. Reports generated by individuals (or on behalf of individuals), can have their role/title included in the name of the report. Alternately, as discussed in more detail below, if the report is specifically aimed at providing information for a specific Working Group or person, then that role/title would be included in the title of the report instead. For instance, a report generated by the Quality Group could have that included in the title (e.g. the QGWPUR discussed above). Alternately, a report being generated specifically for the Chief Executive Officer (CEO), would have CEO in the report name (e.g. the CEOWPS discussed above).

Period Covered by the Report. It is often useful to include the period covered by the report within the name. For example, it is recommended that 'Daily', 'Weekly', 'Fortnightly', 'Monthly', etc. should be a part of the title. This is important for ensuring that the scope of the report is clear.

What is covered in the Report? It is important that the title of the report gives some insights into what will be covered in that documentation. Additionally, apply clear conventions within your reporting schema to ensure that people can readily understand which reports are feeding into a meeting/individual and which are outputs from meetings or from individuals. As an example, you can utilise the following conventions:

Inputs - Documents feeding into meetings/individuals. If the primary objective of a report or document is to feed information into meetings/or individuals these can be defined using terms like 'Agenda', 'Updates', 'Review', 'Discussion Report', 'Evaluation Report', 'Outline', 'Synopsis Report', 'Summary', or similar terms. The context for each will be a little different, so use terms that make the content of that report clear for each level in the reporting hierarchy. However, ensure that you follow the rule that the terms used for inputs are different from those used for outputs. Once you have settled on your convention for this type of report, stick with this.

Outputs - Documents generated by individuals or meetings. Materials where the primary objective is to promulgate information developed from a meeting, or an individual, and not into another meeting, should be defined using terms like 'Progress Report', 'Project (or Program) Report', 'Project (or Program) Update Report (PUR)', 'Resolutions Report', 'Planning Report', 'Strategic Report', 'Assessment Report', 'Minutes', etc. In line with the preceding advice, keep to a convention, so that there is a clear differentiation between what are considered input and output reports.

Your task in the first column is to name all of the various reports. A good starting point is to look at the examples already provided and the slides for Reports and Documents in the Topic 8 workshop (and particularly the Putting Them Together slide) and identify the naming conventions that you will utilise for all of these various reports. There is no absolute correct answer for this. The key is to ensure that names and conventions that you apply are consistent and will make it easy for people to understand where each report fits into the bigger picture.