Page tree
Skip to end of metadata
Go to start of metadata

CII FSC Guidelines for Research Teams

Last Updates: April 2021


CII Research Process and Guidelines

CII Research Process

1. Team Formation

2. Kickoff

3. Research Execution and Methodology

4. Progress Updates

5. Online Rehearsals (if applicable)

6. Report Writing

7. Presentation

8. Close-out

Guidelines for Expected Deliverables

Progress Update Deliverables

Knowledge Base Deliverables

Guidelines for Data Deliverables

Guidelines for Final Reports

Tools and Further Development (validation, deployment, professional development)

Close-out Reports

Summary of Deliverable Links



This document offers guidelines for research projects sponsored by CII. Research projects are projects that create new knowledge, whether as a model, framework, hypothesis validation, technology, or new practice definition. These projects may vary in their duration and organization. The following sections are stated in a way to allow flexibility with respect to the types of research projects. While they provide the baseline for expectations, each project will require specific milestones that reflect the project goals, resources, and constraints. For instance, while a traditional two-year project may require a presentation at a CII annual conference (AC) and two or three rehearsals, a shorter exploratory project may require a webinar. This is important, considering that CII has more frequently departed from the traditional two-year project.

While research teams are tasked with creating new knowledge, CII may launch additional efforts with deployment in mind in order to drive the implementation of research results. These development projects may develop prototypes and tools, benchmarking programs, educational modules or programs, and certification frameworks, as well as knowledge management projects (for instance, preparing special publications and information databases). The guidelines below may apply to these development projects to some extent.

This document starts with a high-level definition of expected outcomes and deliverables. It then covers the research process guidelines, and finally provides a detailed definition of the deliverables.

How to use this document

We recommend that all academics involved in the project should review the entire document and discuss any questions or concerns with CII staff before the kickoff meeting. Academics and team leaders can also use this as a reference throughout the project.

Deliverables and Project Outcomes

Project outcomes are considered models, practices, and/or frameworks that, once applied, can improve the business of organizations in the capital projects industry. Many times, these outcomes are prototyped in a tool that can be readily available the end of the research project. One example of such a tool is the PDRI tool. Other times, this outcome could be a framework that may require further development for implementation; for instance, the Advanced Work Packaging process defined by CII Research Team 272 (RT-272). Although projects may start with a preliminary definition of expected outcomes, CII expects that some changes can occur to the outcomes as the research progresses. The guidelines outlined here create the means for CII to work with research teams to assure that the final outcomes fulfill the original goal.

Project deliverables, on the other hand, are clearly defined early in the project life-cycle (typically, at the proposal approval). The sections on “Expected Deliverables” (below) provide details about these.

The identification of preliminary results, discussed in the methodology section below, deviates from the traditional CII approach of waiting for the final presentation to report the research results. The presentation of preliminary results may be a tool for engagement with, reflection upon, and improvement of the project research. It also allows a perception that value is being provided earlier on in the process, which may be beneficial in an industry where two years can sound like a long-term period.

The goal of the research project is to drive positive change in the way organizations plan and execute capital projects. The delivery of the results must be done in a way that makes the results enticing and drives actual implementation. Often, actual implementation may depend on further development (of tools, for instance). In these cases, it is important that the research team articulates these opportunities in a way that lets other CII committees – notably the CII Deployment Committee work to sponsor this further development where necessary and desirable. These additional development opportunities may generate guidebooks, lessons learned, case studies, online training, and more.

Figure 1 . Research Project Outcomes and Deployment Outcomes


CII Research Process and Guidelines

CII research is a collaborative process with the goal of creating innovative and high-impact outcomes that improve the business of organizations in the capital projects industry. The work is conducted by teams that include academics and industry participants from owners, contractors, suppliers, and service providers. While each research team is unique, all teams should follow a process that ensures the quality and trustworthiness of its research results. This section outlines that process and provides guidelines for teams. Although it is directed primarily to academics engaged in research projects, teams’ chairs and vice-chairs will also benefit from some sections.

CII expects the research to be conducted by a research team composed of academics, including the Principal Investigator (PI) and any co-PIs (research process experts), and industry representatives (domain experts). CII will identify the industry members and establish the team once the academics have been selected. In recent years, CII has encouraged (and sometimes required) the engagement of experts from other domains with the goal of bringing innovations from outside the capitals projects industry. These outside experts are not necessarily the co-PI and can be seen as consultants to the team with specific goals and who participate at specific times during the project rather than throughout the entire project.

While each team develops its own culture and establishes its own norms for operation, CII expects every team to be led by two industry experts selected by CII to serve as “chair” and “vice-chair.” The PI(s), as the process expert(s), will work with the team to develop a detailed research plan, while the chairs will facilitate and lead the overall research effort. In their roles, the chairs will facilitate and promote engagements, serve as spokespersons for the team, and assure that the results of the research will benefit CII’s members.

Expectations for Academics

CII expects academics to drive rigor and innovation in the research. Academic rigor should be driven by the research methodology, and that methodology must be effectively communicated to CII throughout the early stages of the research process. These communications typically happen during progress updates and ad-hoc meetings can be used as needed.

Academics are also expected to find ways to engage and collaborate with industry members by understanding team members’ expectations and driving team building and alignment across the team.

What is new?

If you have participated in CII research in the last 30 years, some of the content in this document may be new for you, particularly:

         The definition of project deliverables

         The format and content of progress updates

         The format and expectations for presentation and reports

         The requirement to identify and better connect to future deployment efforts

We encourage experienced academics to review this document.


CII Research Process

CII expects research projects to follow the process shown below and detailed in this section.

1.      Team Formation

CII will coordinate recruitment for research project staffing, which is done primarily through CII Board of Advisors members. CII aims to balance the participation of owner and contractor organizations and industry groups in projects, and tries to make sure that the team is diverse and represents different perspectives. Most research teams consist of 15-20 members, but team size can vary widely depending upon the topic and the business environment.

Any potential new member identified directly by the current team members needs to be submitted to CII for approval. CII requires CII Board of Advisors members to vet nominations of their organizations’ employees.

Note that, while non-member organizations may provide data and expertise, non-members cannot be part of the research team. This means that they cannot systematically attend team meetings and that they should not have early access to results.

2.      Kickoff

A “standard” kickoff consists of a full-day meeting with the entire team in attendance and hosted by CII in our offices in Austin. CII manages the kickoff meeting, including the invitations to the team members. Alternatively, online kickoffs can be considered, particularly in cases of smaller projects and under unpredictable travel constraints (e.g., pandemic-related restrictions). In preparation for the kickoff meeting, CII has developed short online videos that explain CII’s research organization, process, requirements, and expectations. All members – particularly new members – are expected to watch these videos and complete a short quiz.

The team should use its kickoff meeting to build alignment on project objectives, scope, and its expected methodology and deliverables. During the meeting, the team schedules its face-to-face (F2F) meetings and recurring calls. It is important to block as many F2F meetings as possible, so team members can seek approvals and make travel plans.

Following the kickoff meeting, team leaders meet separately with the Associate Director for Funded Studies, the Research Coordinator, and the sponsoring committees. During this meeting, the CII representatives review the guidelines for deliverables, templates for progress updates, and team milestones. Team leaders are expected to share the proposed schedule for face-to-face meetings and recurring calls. CII staff and team leaders then develop a mutually agreeable schedule for progress updates.

You can find a kickoff checklist here .


3.      Research Execution and Methodology

This section addresses guidelines for meetings, research methodology, and data collection/surveys.

Due to the collaborative nature of CII research, the actual research work occurs in cycles that center around team meetings. Team meetings are critical to organize the project execution. For the academics, this means developing surveys, organizing and managing data, analyzing data, and preparing reports for the team. This work follows the steps defined in the research methodology. The figure bellow illustrates the expectation of engagement for academics and industry members.


Figure 2 . Research Work Cycle Centered on Team Meetings


A research team’s face-to-face meetings beyond the kickoff meeting will be hosted by team members. CII expects two to four face-to-face meetings per year. More meetings may occur early in the process, when scope definition, methodology definition, and data collection are occurring, while fewer meetings may be necessary toward the end of the project, when the team is focusing on writing its report and preparing the presentation. Research teams are encouraged to use web-based meetings to minimize travel impacts on team members. CII suggests that the team schedule a recurring monthly call that can be used as needed. Virtual meetings should be hosted by team members’ organizations’ resources.

With the goal of promoting alignment and good communications, CII will set up a collaborative workspace. As of August 2020, CII uses Trello or Microsoft Planner as the collaborative space for overarching teams. Note that these tools allow planning and document sharing in an online platform. If teams require a messaging tool, CII can provide a Microsoft Teams space. CII does not support Slack although it welcomes teams to set up their own Slack.

CII also encourages research teams to use collaborative tools in online meetings, such as Mural ( ) or Microsoft Whiteboard (and other options that CII has not tested, like Lino – ). CII will support workshops in Mural if requested by research teams.

Guidelines for Research Methodology

CII research has always been valued by CII members because of its trustworthiness and academic rigor. We strive to live up to this expectation and expect academics to drive rigor through their research methodology. To this end, communication about the research methodology becomes a critical issue.

CII’s expectation is not to wait until the end of the project to receive a detailed explanation of the research methodology. The methodology should be communicated early and throughout the entire process, allowing any questions or concerns to be cleared up as early as possible.

The point of departure for the research methodology dialogue is the initial proposal – either submitted to the RFP or developed after a Request for Qualifications (RFQ). If your project did not require a proposal (as in the RFP process), we encourage the sponsoring committee to work with you on a proposal prior to the kickoff meeting. This initial methodology framework is expected to be detailed soon after the kickoff and to evolve over the life of the team.

The methodology discussion in the progress updates should include both a high-level discussion of the methodology and detailed support slides. These detailed support slides may contain information about survey instruments, tests, models, etc.

CII requires teams to complete a methodology summary table, which is a simple way to capture the methodology at a high level (see Table 1 below). Note that this table relies on the premise that the work is broken down in terms of partial deliverables. This summary table is included in the progress update template.  

The “Progress Update” section of this document provides additional information about the methodology content that can be covered during progress updates.



Table 1 . Example of the Methodology Summary Table





Survey data on factors affecting construction readiness

Descriptive analysis of the survey data to identify common factors

Potential factors

Exploratory Phase

Expert input on the relative relevance of factors

Delphi Method

Weighted factors required to create a framework for “Tool A”

Development of the proposed tool’s framework and proof of concept

Project data on cost and schedule outcomes

scores from the implementation of “Tool A”

t-test to identify statistically significant benefits associated with the use of “Tool A”

A statistically significant association between the score produced by “Tool A” and certain project outcomes



Notes on Partial Deliverables

Oftentimes, the entire research process is treated as a single step and outcomes are only provided at the end of this process. By breaking up the work and adding partial deliverables, academics can make the process more transparent and allow for constructive feedback early in the process. CII encourages academics to identify partial deliverables that could be valuable when presented to CII members, but that would not yet be the main contribution of the team.

One example of a partial deliverable is a maturity model, a model that is often included as a deliverable of research teams. While, in general, CII does not see a maturity model as the main goal of a project, they help teams to organize factors that are related to a practice and to evaluate individual projects or companies. For instance, a CII research team recently investigated practices that could enable collaborative scheduling. The group used a maturity model early in the process to identify factors that were associated with collaborative scheduling. This, in turn, helped the team to develop its survey instrument. The maturity model here should be treated as a partial deliverable, which will help the team to align and achieve its ultimate research goal: in this case, to identify practices and tools that allow companies to perform collaborative scheduling.

Another example is the project charged with the task of identifying technologies that can eliminate incidents resulting from last-minute changes. The partial deliverable for the team is the list of technologies identified as potential candidates for the task, ranked according to criteria defined by the team. This deliverable can be provided to members during the project, generating value earlier in the process. The second part of the project is then to adapt and test some of these technologies.

Guidelines for Data Management

This section includes guidelines that span the life cycle of the data starting at the development of data collection instruments, including data collection and the delivery of data to CII. As of September 2020, CII is transitioning toward a more formal data management plan and this section lays out the main expectations.

Guidelines for the Definition of Data Collection Instruments

Research teams are expected to use diverse sources of data – both external and internal to CII, including primary and secondary data. When appropriate, structured interviews, case studies, field trials, simulation modeling, project (“hard”) data surveys, and other data-gathering and data-generating techniques should be considered, provided such techniques and methods produce data, and that the resulting analysis and conclusions are consistent with “rigorous, accepted academic standards following a structured scientific process.”

Data collection sources, data types, and other information related to data collection must be summarized in the “Data Summary” table. A template for this table will be provided by CII (see the Guidelines for Data Deliverables section below for a link to the template).

If a team plans to use surveys, it should carefully plan and evaluate the purpose of these surveys. Many survey instruments (and the questions they pose), although they seek factual data, capture only the opinions of respondents. CII therefore provides the following guidelines for use of surveys in CII research:

         Surveys may be primarily used to solicit ideas, suggestions, target resources, etc., and may also be used to obtain hard project data. As noted above, while non-member organizations may provide data and expertise, their employees cannot be part of the research team.

         Researchers should also recognize that directing surveys only to the CII membership may not result in the desired innovation and broadening of CII member perspectives. There is a risk that surveying CII members could simply reinforce existing practices, processes, and perspectives; inadvertently skew research results; and deny CII members the benefits of broader opportunities, innovations, and viewpoints. This consideration is particularly relevant for technology-related projects.

         CII research team surveys should not be used to generate opinion-based research conclusions unless the intent of the survey is to solicit opinions. Care should be taken in crafting survey questions to avoid unintended confusion between “opinions” and “hard data.” For example, if a well-intentioned question (e.g., “What improvement in X would result if Y were implemented?”) is ultimately an “opinion” question, then so too would be the response. Typically, survey results that reflect the opinions of the respondents might be used in guiding the progress and direction of the research effort but would not be used to validate findings of the research and, in particular, benefits to be derived from the research.

         Any research findings that rely on opinion surveys should be properly qualified to make their origin clear.

Furthermore, the following additional conditions shall be applied to the utilization of CII member (or industry) surveys in executing research:

         Any planned use of a survey instrument must be reviewed and approved prior to distribution by the CII Associate Director for Funded Studies. Such approval shall be secured in advance of the development of the survey instrument. The request for review and approval must identify the basic goals and objectives of the survey approach. Teams should allow for two weeks for review and approval.

         Any such survey request submitted for approval should carefully identify the objective of the survey, which may include:

  • To gather general information, potential research resources, or ideas for innovations or solutions;
  • To gather hard data, typically associated with the Testing/Validation phase of the research.

Guidelines for Research Data and Confidentiality

All data collected by CII research projects in support of research activities are to be considered “company confidential.” Only PIs and their designated academic research assistants will be allowed access to the data collected for CII research projects. The data are provided by organizations with the assurance that individual company data will not be communicated in any form to any party other than CII-authorized academic researchers and designated CII staff members. Any data or analyses based on these data that are shared with others or published will represent summaries of data from multiple organizations participating in the data gathering and collection effort, aggregated in a way that will preclude identification of proprietary data origins and/or the specific performance of individual organizations.

While serving on CII research teams, industry participants may at times have access to aggregated summaries of proprietary, company confidential data as necessary to support the research. These data will be used only for the support of the team research under the guidance of the PI and everyone granted access to the data must execute a CII-provided confidentiality acknowledgment before receiving access.

Guidelines for Reporting Data

Reports, presentations, and proceedings containing statistical summaries of aggregated company data may be used to support research findings. When collecting project-related data, to protect the confidentiality of companies submitting data, all data published and/or presented must reflect the aggregate of no less than 10 projects and must have been submitted by at least three separate companies. In cases where a disproportionate amount of the data is provided by a single company, the PI will suppress publication of results until the dataset is sufficient to mitigate confidentiality and bias concerns. Where smaller samples are used to support case study and field trial research, either a release will be obtained from the companies submitting such data or all confidential identifiers will be removed before using the data. Reports and data files containing individual organization or project data are considered confidential and will not be published or released without specific permission in writing from each company’s representative to the CII Board of Advisors. It is the responsibility of the PI(s) to obtain this permission.

Data Reuse and Derivative Work

A copy of the dataset with confidential company, project, and respondent identifiers removed may be kept by the PI at the completion of the research project to support future academic research and publication needs. CII asks academic to submit derivative works for comments prior their submission to publication in conferences or journals. CII’s goal is to ensure that data are reported according to our guidelines – ensuring the confidentiality of our member companies. Datasets cannot be published or shared with the public in any form.

CII considers the datasets to be part of the project deliverables. These datasets can be leveraged in future research projects and thus may become part of CII’s research database. Teams are required to create data dictionaries (see “ Guidelines for Data Deliverables ” below) that explain the data fields being captured, and to provide these dictionaries to CII along with the dataset.

Guidelines for Validation

While validation is a challenging step in the research process, research teams are expected to conduct rigorous validation of the research outcomes. Exceptions to this rule must be discussed with CII in the first two progress updates. Validation will depend on many factors, including the scope of practices being proposed and the type of data being collected. Table 2 , which is also included in the progress update template, illustrates a few examples of validation approaches observed in past CII projects. Teams should use Table 2 to plot how their project will communicate what type of validation is planned. For example, if a team provides a result that indicates savings of 30% of operating costs over the life cycle of the project and the supporting data were based on an opinion survey that asked respondents about expected savings, this is an opinion-based validation. If no other validation approach is possible, the results should clearly state the original survey questions and possible biases when collecting this data.

Table 2 . Validation Table with Examples

Broad Scope

(all project phases, action by all stakeholders, roadmaps, non-applied topics)

Productivity research roadmap

Regulatory Roadmap


E.g., AWP Framework Validation



Flexible Facilities

PUI Standardization



Narrow Scope

(one phase, action by few stakeholders, simple   tool)





Construction Readiness

VR Project


Type of Validation>

No Validation

Opinion-based Validation

Small Number of   Cases

Quantitative Validation


Color Legend

Not Acceptable




4.      Progress Updates

CII schedules progress updates as well as ad-hoc calls with the teams to monitor project progress. The primary focus is to capture progress in terms of methodology, but logistics issues like staffing, attendance, and schedule should also be addressed.

The team leadership (chair, co-chair, and PIs) is expected to attend these calls along with CII staff and sponsoring committee representatives.

The team should prepare slides to support the scheduled progress updates and to submit these slides before the call. If a team is sponsored by a Sector committee, its progress updates should be scheduled separate from committee meetings. Each progress update will enable participants to address any issues regarding scope, objectives, or research methodology (e.g., surveys, data analysis) early in the process, rather than during later phases such as presentation development or report writing/review. The team should also revisit and update its project methodology table during each update (see Table 1 in the “Guidelines for Research Methodology” section above for an example).

For a typical two-year research project, the following items summarize the expectations for progress updates. These should be adjusted for other types of projects:

  • Progress update 1 focuses on alignment and refining objectives and may revisit the project methodology table.
  • Progress update 2 focuses on methodology and revisits the methodology summary table.
  • Progress updates 3 and 4 focus on partial results and deliverables.
  • Representatives of the CII Deployment Committee will be invited to attend progress update 3 and any other subsequent meetings (such as annual conference rehearsals) when participants could be expected to identify deployment opportunities for the team’s products.
  • The team may consider delivering partial results that will provide value to members and build interest on the project. These may include a white paper, blog post, or some other vehicle to disseminate findings to CII members in an agile way.
  • The team should identify its expected final deliverables at progress updates 3 and 4.
  • The team should be prepared to identify opportunities for further deployment of its research results. For instance, if the team identifies a need to benchmark the use of a tool or practice, the Deployment Committee may propose integrating the results into the CII Data Warehouse and benchmarking efforts.

5.      Online Rehearsals (if applicable)

The online rehearsals will help the team to create and develop a narrative that focuses on the value of the research results and entices the audience to implement the research outcomes. This means that the narrative should start with the end in mind, providing clear insights on the benefits of the research outcomes and the problems they address.

Online rehearsals are not included in the initial project schedule. CII will schedule a conference call to lay out the plan for the rehearsals and other steps in preparation for the presentation.

Online rehearsals are attended by the CII Associate Directors, CII Annual Conference Committee members and CII Staff, as applicable. All are invited to attend and give feedback.

Research teams should expect one to three online rehearsals (with one-year projects having fewer sessions than two-year projects). Early rehearsals will focus on developing the storyline for the presentation, and later session(s) will focus on the slides and improving the storyline. The goal is to prepare a set of slides that supports a compelling narrative, and to have them ready for the final presentation.

For teams presenting at a CII Annual Conference, before the last rehearsal, the team is expected to implement the changes captured during rehearsal(s) and submit an updated set of slides to CII, which may contract with a graphic designer to improve their appearance and function. The graphic designer will provide the revised slides to the team ahead of the last rehearsal.

6.      Report Writing

The team leaders will coordinate the final report write-up and the team’s industry members are expected to help in the report writing. Report writing should leverage the presentation’s storyline and graphics. Teams will coordinate with CII regarding submission dates for report drafts and final reports. For teams that present at the Annual Conference, CII may not be able to review, edit, and publish all reports ahead of the event. Some teams may be able to provide their final reports in time for publication before the conference, while others may elect to publish their reports after the conference. Note that, in any case, the results of the projects will be summarized in the CII Knowledge Base in time for the conference. The milestones for report delivery will be revisited during the online rehearsals and new deadlines may be defined. The CII editor will work with each research team on the review of its final report.


7.      Presentation

The standard presentation vehicle for a two-year project is a live presentation at a CII event. These are 30- to 40-minute presentations that require considerable effort (rehearsals) to produce an enticing presentation. Some examples of past presentations at CII Annual Conferences are provided for reference:

         RT-335 presentation (2018 AC)

         RT- DCC-02 presentation (2018 AC)

         RT- TC-02 presentation (2019 AC)

Online presentations

Alternatively, teams may present their results in an online webinar. This is particularly applicable to teams with shorter duration (one-year projects). CII will coordinate with the team to record the presentation in advance and schedule a live event that includes Q&A.

Regardless of the type of presentation, CII recommends that presentations should be led by industry members with the limited participation of academics. This delivery helps industry members to connect with their peers, offers them a professional development opportunity, and helps members to mature the narrative in a way that they can also apply during report writing, discussed in the following section.


8.      Close-out

Each team will submit the close-out report no later than the date in the research team’s contract. The CII research coordinator will send reminders and follow up with teams in preparation for the project close-out.


Guidelines for Expected Deliverables

The following sections describe deliverables to be provided by the research team:

  • Three or four progress updates, including data summary updates, methodology summary update, and updates to the connection to deployment
  • One or more online rehearsals and a final presentation at a CII event
  • A Knowledge Base Topic Summary and a Tagging Checklist (see Knowledge Base Deliverables below)
  • Data summary table and datasets with raw data and respective data dictionaries
  • Final report
  • Close-out report

Optional deliverables:

  • Proof-of-concept tools or beta software (if applicable)
  • Case studies to be published as standalone documents

Progress Update Deliverables

The progress update deliverables consist of a slide presentation following the provided PowerPoint template, along with participation in a progress review conference call.

Progress updates typically consist of two parts: Research Approach and Logistics.

The Research Approach, at a minimum, will address the following:

  • Research objective(s), problem statement(s), research questions, and research value
  • Expected deliverables
  • Research methodology (including the methodology summary table)
  • Data collection and management including:
    • any request for review and approval of survey instruments
    • an updated data management summary (see Guidelines for Data Deliverables below)
    • any request for data collection support
  • Preliminary and final results
  • A review of the opportunities identified for further development by the Deployment Committee

The Logistics section of the update will present the following:

  • Current project schedule
  • Research team attendance and engagement, including any request for additional members

The progress update template may be accessed here .

Tables 3 and 4 below describe items to consider in progress updates, sorted by the timing for reporting.

Table 3 . Progress Updates Checklist – Methodology Update


Not Available

Not Applicable

Not Changed since Last Update






Problem Statement





The problem statement is clear and well-articulated





The research question(s) is(are) provided and is(are) clear,   concise, and complete





The variables being investigated are   clearly identified and presented





Reference to Previous Work





Relevant literature including CII and non-CII publications is referenced and is shown to be comprehensive





Points of departure are clearly defined





Research Methodology





Methodology table is provided and is complete and clear





The methodology is shown to be appropriate for the research question





Validation has been addressed in the research methodology and methodology table





Data Management





Data management summary file is up to date





All survey instruments have been referenced





Survey instruments have been provided to CII for review and approval





Which datasets to provide to CII has been discussed





Data collection has been described and issues are identified





Data collection support has been requested





Data Analysis





Statistical tests/methods are shown to be appropriate





Data analysis details are included in supporting files





Reporting Findings





The assumptions underlying the use of   statistics are considered





The statistics are reported correctly and appropriately





Preliminary results have been included





Presentation of Results





Shows how results can be organized in a way that is easy to   understand





The results are contextualized – update shows how results are related to practice





Includes tables, graphs, or figures that are key to effectively communicating the results





Includes clarifications about the interpretation of results and validation procedures (particularly in research relying on opinion surveys)





Discussion and Conclusions – Interpretation





Practical significance of results is discussed





The study limitations are discussed


Table 4 . Progress Update Checklist – Project Logistics


Responsible Party

Complete (Yes/No/NA)

Send progress update slides to FSC AD and Research Coordinator 2-3 days before the call

RT Leaders


Provide updates on team attendance and engagement

RT Leaders


Provide updates on future calls and meetings

RT Leaders


Provide updates on new members

RT Leaders


Provide updates and schedule and budget

RT Leaders



Knowledge Base Deliverables

Each research team must provide two deliverables that allow the dissemination of the research results in the C II Knowledge Base (KB):

  • The topic summary is a concise description of the research. It is available to any user who accesses the KB (not only CII members). It draws attention to the final report and any other available publications and deliverables, and it motivates users to access these resources. Many examples can be found in the KB. A template for the topic summary is provided here.
  • The tagging checklist is an Excel file that provides the metadata that connect the topic summary to other parts of the KB. A template of this checklist is provided here.

Topic Summary

The topic summary gives an overview of the research and its findings. It should be limited to 3-4 pages and contain the following content:

Topic Summary Heading: The heading should provide the team’s number and title (e.g., R esearch Team 283, Industrial Modularization) .

Overview/Conclusions: The summary should concisely summarize the topic, establishing its importance, identifying the key conclusions and recommendations, and conveying the value and benefits of implementing the findings:

  • Overview/conclusions section – This section should be no longer than one page.
  • Bookmarks – Each piece of information should be bookmarked to give the location(s) in the research publications where effective explanation(s) can be found with a document number, page (locations), and/or figure/graphic location(s) (e.g., IR283-2, page 10, Figure 3).

Key Findings (Supporting Graphics and Information): The topic summary should list the key findings, data, and information that support the conclusions presented in the overview/conclusions section. Limit the material to only the most relevant and necessary data, with no more than eight key findings. This presentation of key findings should not be so exhaustive that it eliminates the need for the reader to obtain any of the research publications, especially since this summary will be available to all readers online. It should only give enough detail to establish the value of the research and to motivate the reader to obtain the publications. For each key finding, the team should provide:

  • The document number, page number, and/or graphic location at which each finding appears in the research publication (e.g., RR283-11, page 44).
  • Key finding illustration – If appropriate, suggest a graphic that illustrates each finding cited and import it into the template as shown in the examples below.


Key Finding #1: Developing and Weighting Readiness Factors

RT-DCC-02 derived 228 construction readiness factors spanning 15 categories. Using data collected from 80 projects, the readiness factors were weighted. A higher weight indicates a higher contribution in differentiating CR from CNR projects.


Reference:   (FR-DCC-02) , page 13

Key Finding #2: Construction Readiness Score

Using the developed weights, the team created the Construction Readiness Score (CRS), which is a single unified metric that can be used to assess the readiness level of a project as a percentage. The CRS was then benchmarked to be used to classify future projects in one of three categories:

  • Construction-Not-Ready (CRS between 0% and 75%)
  • Borderline (CRS between 75% and 85%)
  • Construction-Ready (CRS between 85% and 100%)

Reference: (FR-DCC-02), page 33

Figure 3 . Example of Figures Illustrating Key Findings


When reporting the key findings, the team should leverage the graphics from the final presentation. Figure 4 provides an example of a preferred way to communicate findings. This attractive graphic is from a presentation that summarizes the benefits RT-DCC-02 found for “construction ready” projects. Figure 5 is an example of a figure that should not be used. Although it portrays the same results, it uses a dense chart generated from statistical software.


Figure 4 . Example of a Figure that Summarizes Findings (Recommended)



Figure 5 . Example of a Figure Obtained from Statistical Software (Not Recommended)

Implementation Tools

If applicable, identify and list any key spreadsheets, checklists, directions, and other implementation guidance. Provide bibliographic information to direct readers to the tool(s), as is demonstrated above in the samples of key findings.

Key Performance Indicators

Identify which key performance indicators the research topic area affects.

Research Team Publications

Provide a list of all research publications the team has produced. This list will be used to create links to each publication. See the session below on other academic publications not included in the team deliverables.

Supporting Resources

The team’s page in the CII Knowledge Base will include additional resources that its members developed:

  • Presentations – The KB will reference any presentations (including to the CII Annual Conference, CII Board of Advisors meetings, or workshops) that support the team’s recommendations or show how to implement its materials.
  • Educational materials – The KB will list any CII educational resources that support the topic area. The team is welcome to volunteer information for this listing.

Other Items

This section can be used if the review of the research material identifies special items of interest, such as key definitions, key synonyms, and related follow-on research.

Other Academic Publications

CII wants to provide links from the KB to any academic publications that result from the research. Most of these links are expected to be provided after project completion, and CII asks PIs to provide this information as soon as these publications become available. When the team delivers its topic summary, it should provide links to any publications that are already available. CII will only include a link to these external publications, and it is understood that some publications may require purchase (particularly papers in academic journals).

Guidelines for Data Deliverables

CII expects any data generated by this RT to be submitted to CII at the project close-out and will include:

  • An updated version of the data summary table (see a template here ). As a rule, CII will include this template in the collaborative space created for the project. Teams without a collaborative space will receive a copy via email. This data management summary tab must be updated frequently and may be reviewed at progress updates.
  • Data in Excel or other database format approved by CII. Data should be provided through link to secure cloud storage.
  • Data dictionary (following the format provided in the data management table above).
  • Copies of surveys used, including project data survey and/or opinion survey.

Guidelines for Final Reports

The final report is a summary of the team’s research and its deliverables, written for the industry practitioner (a project management or business unit decision-maker). While the progress report has an academic emphasis (on the methodology), the final report emphasizes the value and implementation of the results for the CII industry member. In other words, while the progress report starts with the research question(s) and builds up the methodology and results, the final report starts with the end in mind by discussing the value of the results and how they can be implemented, and then provides insights on the methodology used to achieve the results. Figure 6 below illustrates this distinction.

Progress Report Sequence


Final Report Sequence

Figure 6 . Content Sequences for the Progress and Final Reports

The final report must accomplish the following objectives:

  • Clearly communicate the value and benefits of the results, following a narrative similar to the team’s presentation.
  • Explain and illustrate how the results can be deployed in capital projects and organizations.
  • Address the interests and concerns of project management and business decision-makers in the construction industry. (This report is not aimed at academia.)

The final report should be written, preferably, by industry practitioners. CII expects that the RT’s principal investigators (PIs) and Chair may coordinate the development of the final report; however, the actual writing is expected to be performed by industry members of the team. One approach has been for each member to write the section of the report that parallels his or her part of the conference presentation in order to leverage that familiarity with the topics. The final report should be written in language and at a level of detail suitable to its intended audience. The sections below describe the expectations for the report content. Note that these are not recommendations for how to organize the report, but only guidelines for its content.

Describing the Value

The final report can leverage the presentation’s approach to communicate the value of the research findings to CII members. For instance, RT-DCC-02 (i.e., the Construction Readiness team) summarized potential challenges faced in construction projects and described the research findings as shown in the figures below.

Figure 7 . Example Illustration of Research Motivation

Figure 8 . Example Figure to Describe Research Findings’ Value


How the final report describes the implementation of project findings may vary significantly, depending on the outcomes’ level of complexity. For instance, the results may range from a simple checklist to an ambitious practice that requires the user to implement major organizational changes (e.g., Advanced Work Packaging).

The implementation recommendations should cover the following considerations:

  • Overall process. The research team should provide a short description of the process.
  • Implementation complexity. Highly complex implementations will require major organizational changes across the project and company organizations. Simple implementations can be accomplished by one or two people on the project team with minimal support. 
  • The timing of implementation and project phases . Implementation can span one or multiple phases. Alternatively, implementation can occur at a specific time in the project; for example, implementing a tool to evaluate project complexity.  
  • Stakeholders. Include a short description of key roles that are responsible and accountable for the implementation.

The implementation of proposed practices and processes can also be explained by presenting one or more case studies and/or through a process flowchart. In preparing supporting figures and tables, please remember that the final report is produced on letter-sized pages (8.5" x 11"). Complicated charts that are difficult to read in a larger format will become illegible in the final format. Please contact the CII Editor with any concerns or questions.

Research Methodology

The research methodology should be addressed at a high level. The intent is to provide insight on how the team collected data and evaluated the results, and to convey the academic rigor in the process. This means that a high-level explanation of the methods should be provided; for instance, explaining why certain methods were adopted, and their objectives. If the researchers developed a model to predict the probability of high-impact accidents, insights could be provided by describing the objective of the model and the variables used for the prediction. The formulae and results of statistical software could be provided in an appendix.

Finally, the final report should convey the results in a clear and fair manner. The team should avoid making unfounded extrapolations of the results and should state benefits strictly supported by the research findings.

Tools and Further Development (validation, deployment, professional development)

As a rule, CII expects research teams to create new knowledge and to test and/or validate any concepts or practices proposed by the team. As part of this process, teams may develop prototypical tools (e.g., Excel tool or beta software) to help test or validate new concepts or practices. CII will treat such tools as proof-of-concept and make them available to CII members; however, CII will not maintain these tools. In cases where the research team develops proof-of-concept tools, the Deployment Committee must be engaged to assess which steps should be taken to enable the further development of these tools. The Deployment Committee will be invited to attend progress updates in order to identify opportunities for the deployment of the research results before the end of the project.

Close-out Reports

The close-out report must be submitted no later than the date in the research team’s contract. The close-out report ensures that all deliverables have been submitted and a final budget is communicated to CII. The close-out report template can be found here.

Summary of Deliverable Links

Kickoff Checklist

Progress Update Template

KB Topic Summary Form

KB Tagging Checklist

Data Management Template

Project Close-out Form


  • No labels