How to build your own project template in Word or PowerPoint?

In this article we will learn how to build a custom project template in Word or PowerPoint. 

How do templates work?

In addition to normal text, templates contain binding elements that are replaced with the values they represent when the template is applied to a project. As the binding elements do not represent a specific project, the same template can be applied to any projects.

Below is an example of a project template. Curly brackets are used to identify binding elements. 

When the template is exported from a project, the binding elements are replaced by the values of the project data they represent. Here is an example of a template output.

The instructions given in this article to build your own templates apply to both Word and PowerPoint templates unless otherwise specified.

Deciding on whether using Word or PowerPoint is therefore entirely your choice and each one has its advantage. 

• One downside of using PowerPoint templates is that if the content of a slide overflows, the content does not move to the next slide as PowerPoint does not support this feature. You may therefore need to adjust the format of the generated template a little to make the content fit on the slide. 
• However using PowerPoint template format gives you greater flexibility to export sub projects content as you can see in this article.

General rules when building your own template

• Templates are built using binding elements that reference specific data attributes.
• Curly brackets are used to identify binding elements. 
• The main object names used to retrieve project data include: Project, StatusReportThis, Schedule, Craid, Outgoingdep, Incomingdep, Subproject, Actions, QualitativeBenefit, QuantitativeBenefit, QualitativeCost, QuantitativeCost and ProjectFinancials. 
• If the object is not a list of items, you can access the properties of this object by appending the name of the property to the object name. For instance, {Project.Name} binding element represents the name of the project the template is run from or {StatusReportThis.Strapline} references the status report strapline.
• If the object represents a list of items (impacts, schedule tasks, incoming and outgoing dependencies, etc.), a table needs to be used to iterate through the list of items. 
  • The table must have a header row and the first cell of this row must specify the binding element of the object you want to retrieve the data for. For instance, if the table should list all schedule tasks, the first cell of the table needs to start with the {@schedule} binding element. The @ symbol is used to represent the iteration through all schedule items.
  • The next row should specify the properties of the object you want to retrieve. In the example of the schedule table, the biding element {Title} represents the title of the schedule task. Note that in this case there is no need to prefix the property by the object name. 
  • When the template is applied to a project, the table will have a row for each items in the list that is being returned, e.g. a row for each schedule task.
• You can also apply filters to table elements. As an example, if you want to return only the project's risks and issues that are Amber or Red, you can do so by using the following syntax: {@craid}[^Type=Risk,Issue && Rag=Red,Amber]. 
  • Square brackets are used to delimit filters and there can be no space between the binding element and the filter.
  • The following operators are supported: =, != , < and > operators. 
  • When filtering on dates, you can compare the date to Today or to any date. The date must be expressed in yyyyMMdd format. For instance, [^DueDate<Today] means that the due date must be earlier than today. [^DueDate>20200518] means that the due date must be after 18 May 2020. 
• WORD TEMPLATES ONLY
  • Rich Formatting will pull through to word templates. If you would like your word template to pull through the rich formatting you have used in fluid you need to remove the word "Plain" from the binding element and add [RICH] after the binding element. 
  • For e.g. {Project.DescriptionPlain} will return the description in plain format, if you would like your report to pull through the bullet points, bold, font changes then you need to use the following binding element {Project.Description}[RICH]

Once your custom template is ready, you just need to upload it to start using it. Custom templates can either be shared across the application or be made private to a project.

• For a template to be available on all projects and watchlist pages, it needs to be uploaded under General Settings by a System Administrator. 
• Project managers can also use their own templates on specific projects by creating and uploading the template to the Documents section of the Project Workspace. Define the 'document type' of the uploaded template as Dashboard Template. The new template will appear along with all the global reporting templates in the export dialog on the project.

We will explain in the next sections how to export the project data by data type. Just click on the section title if you would like to jump to a specific section. 

1. Exporting project information and meta-data

• Exporting project phases
• Exporting project custom properties

2. Exporting project status data

• Exporting the project status component RAGs

3. Exporting project schedule tasks

• Exporting the Gantt image

4. Exporting project impacts

5. Exporting project incoming and outgoing dependencies

6. Exporting project financials

7. Exporting project benefits

8. Exporting project ongoing costs

9. Exporting project actions and decisions

You can also see examples on how to use the binding elements in the templates attached to this article.

To learn more about exporting data for sub projects and project hierarchy, please refer to this article.

1. Exporting project information and meta-data

• The object name to use to export the project details and meta-data is Project.
• The format of the binding element for a project property therefore is {Project.PropertyName} 

The table below lists the properties that can be used to retrieve the project information.

^(*)Note that the bindings elements for the project description, proposed solution and requirements return the plain text with no formatting.

Exporting project phases

If you need to export the project phases, you need to use a table to embed the binding elements as each project can have a different number of phases. The first cell of the table must contain {@ActivityPhases} element to indicate that the table should list all phases. Phases only have two properties:

• {Phase} - the name of the phase
• {StartMonth} - the month and year the phase starts on. 
• {EndMonth} - the month and year the phase finishes on.
• {Order} - the phase order number.

Here is an example on how to export the project phases:

Exporting project custom properties

The syntax to export project custom properties is as follows: {Project.ExtProperties.CustomPropertyName}. 

As an example, if the name of a custom property is 'Program Delivery Lead', then its corresponding binding element is: {Project.ExtProperties.Program Delivery Lead}.

2. Exporting project status data

You can use the binding elements to retrieve the details of the current status report as well as the previous status report.

• Prefix the status report properties with {StatusReportThis.-} to retrieve the information of the latest status report
• Prefix the status report properties with {StatusReportLast.-} to retrieve the information of the previous status report

The table below lists the properties that can be used to retrieve the status report details. The table shows the properties for the current status report but just change the prefix of the binding elements to StatusReportLast if you need the previous status report data.

^(*)Note that the bindings elements for the status report achievements and next steps return the plain text with no formatting.

Exporting the project status component RAGs

There are two ways of exporting the project status component RAGs.

The first option is to use a table to iterate through the component RAGs. The benefits of using this approach is that you do not have to explicitly name the component RAGs in the binding elements and therefore the template does not need to be updated should the component RAG names change.

When creating a table to export the component RAGs data,

• the first cell of the header column must start with either {@StatusReportThis.ComponentRags} or {@StatusReportLast.ComponentRags} to indicate that the table should iterate though the current or previous status report component RAG data.
• any of the below binding elements can then be used.

Here is an example of a table returning component RAG data:

Few things to note in the above example:

• In the first cell,
  • StatusReportThis indicates that this data should be for the most recent status report.
  • The filter [^Value=Red,Amber] indicates that only component RAGs that are amber or red should be returned.
• The next row specifies which properties of the component RAGs should be retrieved. 
  • In the case of the RAG value property, it is possible to apply the value as the cell background colour, i.e. display the cell with a red background colour if the RAG is red. To do so, you need to append [BK_COLOR] immediately after the binding element with no space in between, e.g. {Value}[BK_COLOR].

The second option to export the project status component RAGs is to explicitly reference the component RAGs to retrieve their value. For instance, if Financials is one of the project status component RAG, you can retrieve its properties by using {StatusReportThis.ComponentRags.Financials.PropertyName}. 

The list of properties that can be used is detailed in the table below. Name represents the name of the component RAG. {StatusReportThis} can be replaced by {StatusReportLast} if needed.

3. Exporting project schedule tasks

A table must be used to export schedule tasks.

• The first cell of the table must start with {@Schedule}.
• The following binding elements can be used to retrieve schedule task data.

⁽¹⁾This is the plain description with no formatting.
⁽²⁾{AllStatusUpdates} returns the date and the status update strapline for all status updates. The list is displayed in the reverse chronological order.

Here is an example of a table returning schedule tasks data.

Exporting the Gantt image

You can also include an image of the Gantt chart.

To do so, you need to use the fooling binding element in a table: IMAGE_SCHEDULE. The Gantt image will then render all the schedule tasks that have been set to PROMOTED.

The below images show an example of a template using the image binding element and how it renders when exported from a project.

4. Exporting project impacts

Exporting project impacts is very similar to exporting schedule tasks. A table must be used to iterate through the project impacts.

• The first cell of the table must start with {@Craid}.
• The following binding elements can be used to retrieve impact data.

⁽¹⁾This is the plain description with no formatting.
⁽²⁾{AllStatusUpdates} returns the date and the status update strapline for all status updates. The list is displayed in the reverse chronological order.

^{(3) For Impact, Probability & Risk Rating, the label/title that has been defined under Project SetUp will be the name that is used in the binding element}

Below is an example of a table returning only risks and issues.

5. Exporting project incoming and outgoing dependencies

A table must again be used to export incoming or outgoing dependencies.

• The first cell of the table must start with {@OutgoingDep} to iterate though the project outgoing dependencies.
• Use {@IncomingDep} to iterate though the project incoming dependencies.

The following binding elements can then be used to retrieve the outgoing or incoming dependency properties.

⁽¹⁾This is the plain description with no formatting.
⁽²⁾{AllStatusUpdates} returns the date and the status update strapline for all status updates. The list is displayed in the reverse chronological order.

The image below gives an example on how to use these properties.

6. Exporting project financials

• The object name to use to export project financials is ProjectFinancials.
• The format of the binding element for a project property therefore is {ProjectFinancials.PropertyName} 

The table below lists each financial value available for extract with the following info for each:

• Input vs. System: Whether the value is a manually entered value or whether it is a value generated by Fluid based of other input values and configuration.
• Binding element: The string to use in the reporting template to populate the required value out of Fluid.

Below is an example on how to export project financials data.

7. Exporting project benefits

You can export both quantitative and qualitative benefits. To do so, you need to use separate tables with the following elements:

• {@QualitativeBenefit} to display the list of qualitative benefits.
• {@QuantitativeBenefit} to display the list of quantitative benefits.

The list of benefit properties that can be exported are listed in the table below.

^(*)This is the plain description with no formatting.

You can see examples on how to export qualitative and quantitative benefits below.

8. Exporting project ongoing costs

Exporting ongoing costs works in the same as as exporting benefits. You need to use separate tables with the following elements:

• {@QualitativeCost} to display the list of qualitative ongoing costs.
• {@QuantitativeCost} to display the list of quantitative ongoing costs.

The list of ongoing costs properties that can be exported are listed in the table below.

^(*)This is the plain description with no formatting.

9. Exporting project actions and decisions

The complexity in exporting action and decision data is due to the varying number of assignees actions and decisions may have. Actions and decisions are represented differently depending on whether they have one or more assignees and therefore different binding elements need to be used.

As it is not possible to filter actions and decision based on their number of assignees, the table used to return action data must support both types of actions and decisions if you want to export the assignee names and the action or design status.

Let's first look at the binding elements that can be used for actions and decisions.

^(*)This is the plain description with no formatting.

Now let's look at how to build a table that returns decisions with the list of assignees and the response of each assignee.

The following examples of how the tables are built to return decisions apply Word & PowerPoint templates. 

• Word template

• PowerPoint template

Few points to notice in the above examples:

• Elements in the first cell of the header row:
  • The first cell of the header row starts with {@actions} to indicate that the table should return actions and decisions data. 
  • The filter element [^Type=Decision] then indicates that only decisions should be exported.
  • Finally, [SubRow] element needs to be added to indicate that the decision assignee and response should be returned.
• The columns containing the assignee names, status and response must be consecutive and the cells need to be split in two rows.
  • The order of these columns does not matter but the fist column must indicate how many columns are used to return assignee data. In the above example, [SplitRow=3] indicates that the next three columns are used to export the response of the decision assignees. If you decided to return only the assignee name and status, then you would need to specify [SplitRow=2].
  • You then need to use the binding elements for both single assignee and multiple assignee actions as highlighted in blue and green in the above example.
  • Finally, {} on the second row indicates where rows will be inserted in the case of multiple assignees. This final step only applies for Word Templates. 

The image below shows an example of how the decision data is exported using the above template.