CII FSC Guidelines for Research Teams

Updated June 2023


Topic Definition
Team Staffing

Proposal Development
Research Execution

Guidelines for Implementation Resources
Knowledge Base (KB) Deliverables


CII, based at The University of Texas at Austin, is a consortium of leading owner, engineering-contractor, and supplier firms from both the public and private arenas. CII's mission is to provide a research and development platform to create and drive innovative solutions that tangibly improve business outcomes through an academically based, disciplined approach.
This document provides guidelines for research projects sponsored by CII. CII research projects are intended to create new knowledge, whether as a model, framework, hypothesis validation, technology, case study, or new practice definition. While these projects may vary in their duration and organization, all will follow the baseline process that is outlined in this document, which can be adapted as required.

CII Research: Starting with the End in Mind

The ultimate goal of the research project is to improve the way organizations plan and execute capital projects. It is important for research team members to start CII research projects with this end in mind and to deliver research outcomes that have the potential to improve project delivery.
Figure 1 shows the process for applied research and development. Improvements may come in small increments or step-changes. In more tactical research projects, this means outcomes that create or change procedures, including practices and tools that can be implemented by practitioners. In other cases, outcomes may provide high-level insights on changes and opportunities to be adopted by the industry.

Figure 1. Applied Research and Development
Project outcomes are considered models, practices, and/or frameworks that, once applied, can improve the delivery of capital projects. In many cases, these outcomes are prototyped in a tool that will be readily available at the end of the research project (e.g., the PDRI tool). Other times, the 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).
The definition of the outcomes may evolve as the research team advances its work, and CII expects to have well-defined project outcomes by the midpoint of the project (the end of year one in two-year projects). A substantial amount of work in the second half of the project goes into the development of these outcomes.
The guidelines presented here create the means for CII to work with research teams to assure that the final outcomes and deliverables fulfill the original goal.

Roles and Responsibilities

Throughout the research project duration, academic and industry members of the team collaborate following the roles and responsibilities listed in the figures below. 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), serving 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 engagement, serve as spokespersons for the team, and ensure that the results of the research will benefit CII's members.

Figure 2. Academic Members – Roles and Responsibilities

Academics drive rigor and innovation in the research process. This rigor should be guided by a research methodology that must be effectively communicated to CII throughout the early stages of the research process. These communications typically happen during progress updates, but ad-hoc meetings can be scheduled as needed. Academics need to find ways to engage and collaborate with the industry members of the research team by understanding their expectations and driving team building and alignment across the group.
The figures below describe the roles and responsibilities for the industry members of CII research teams.

Figure 3. Industry Members – Roles and Responsibilities

Figure 4. Chair and Vice-chair – Roles and Responsibilities

CII Research Process

Figure 5 shows the life cycle of a research project, which is detailed in the remainder of this document.

Figure 5. The Phases of a Standard Two-year CII Research Project

Research Team Scorecard

CII is adopting a scorecard to capture and communicate the health of individual research teams. Throughout the process outlined and discussed in this document, CII will assess research project performance by using the criteria and methods described in Table 1. This scorecard is developed based on input collected from RT members as well as other industry members and academics outside the team.
Table 1. Filled-out Example of the Report Card (with Data Sources and Timing) to Be Used to Assess Research Project Performance





Sources / Method



Mid- project








RT member satisfaction




Survey(s) (Team members' feedback)

Scope and direction




Reviewer feedback





Academic Reviewer feedback

Data collection 



Reviewer feedback

Value and deployment


Value is not clear / not explained




Survey, Reviewer feedback



Not provided / not clear



Reviewer feedback

During project updates, CII staff and members of CII committees will evaluate the health of the research team and provide input that is reflected in the scorecard for project teams. This scorecard may be shared with RT leaders along with specific feedback collected following the update.

How to Use this Document

We recommend that all academics involved in the project should review this entire document and discuss any questions or concerns with CII staff before the kickoff meeting. Academics and team leaders should also use this as a reference document throughout the project.
The following sections are stated in a way that allows flexibility with respect to the types of research projects. While these sections provide the baseline for expectations, each research project will require specific milestones that reflect its 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 to four rehearsals, a shorter exploratory project may require a webinar. This distinction is important, considering that CII has recently departed from the traditional two-year project with increasing frequency.

Topic Definition

CII research topics are developed in a collaborative ideation process. Ideas for research topics are proposed by CII committees, Communities for Business Advancement, and individuals. CII prioritizes and further develops these ideas in collaboration with industry members, a process that culminates in a topic summary.
The topic summary is a short document that outlines the research topic, indicating the problem or opportunity being addressed, the research question(s), and expected outcomes. CII then uses this document as it requests qualification submittals from the academic community as well as participation nominations from industry members. Examples of past topic summaries can be found here:

Team Staffing

Academic Members

Academic members are selected via Request of Qualifications (RFQ), Request for Proposals (RFP), or sole sourcing. CII engages panels of industry members and academics during its selection of RFQs and RFPs. CII has encouraged (and sometimes required) the engagement of experts from other domains with the goal of bringing in innovations from outside the capital projects industry. The outside expert is not necessarily the co-PI. The outside expert can be seen as a consultant to the team with specific goals, who participates at specific times during the project rather than throughout the entire project.

Industry Members

CII coordinates the 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 its projects and tries to make sure that the team is diverse and represents different perspectives. Most research teams consist of 15 to 20 members, but team size can vary widely depending upon the topic and the business environment.
After the kickoff meeting, any potential new members who are identified directly by current team members need to be submitted to CII for approval. CII requires CII Board of Advisors members to vet any 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 non-members cannot systematically attend team meetings. Where applicable and in consultation with CII, non-members that contribute to the project in some fashion, may be invited to mid-project webinars.

Proposal Development

After academics have been selected via RFQ or sole sourcing, they will develop a proposal prior to team kickoff. This proposal will be the basis for the research contract and will also serve as an initial charter for use during the research team's kickoff.
CII's Research Coordinator will coordinate meetings with the selected academics and, where possible, include industry members in the development of the proposal. At a minimum, industry members will review the proposal and provide feedback before final approval by the Associate Director for Funded Studies. These industry members should preferably be familiar with the topic and have participated in the development of the topic summary. Although the proposal development process is managed by the Funded Studies Committee, industry members supporting the proposal development may come from any committees or CBAs that may be close to the topic. These industry reviewers may include members of the research team who have already been identified and may be strategically engaged during its early stages.


A "standard" kickoff traditionally consisted of a full-day meeting with the entire team in attendance and hosted by CII in its offices in Austin. However, since 2020, CII has opted for online kickoff meetings, which are generally planned as two two-hour sessions. Regardless of the format, CII manages the kickoff meeting, including the invitations to team members.
CII leads the kickoff coordination in collaboration with the principal investigators, the RT Chair, and its Vice-chair (if identified ahead of the kickoff). Table 2 shows a checklist to be addressed in preparation for the kickoff.
Table 2. The Activities and Responsible Parties Associated with Kicking off a CII Research Team

Pre-kickoff Activity

Responsible Party

Schedule a kickoff planning meeting 30 days before the kickoff day
Topics include: kickoff objective and agenda, collaborative space, RT leadership, draft deck of slides


Review team membership to ensure that it is diverse and large enough

Associate Director (AD), PIs, Coordinator

Identify and discuss potential chairs and vice-chair (or recommend waiting for kickoff)

FSC AD and Coordinator

Call potential team leaders and inquire about their interest to lead

AD or PIs

Approve names for RT chair and vice-chair

FSC Chairs

Plan an activity to drive engagement at the kickoff (e.g., brainstorming)

RT Leaders

If RFQ: align with Funded Studies Committee members and/or selected RT members ahead of kickoff to develop a draft proposal

FSC AD/Sponsoring Committee, PIs

Prepare RT slides as discussed during the kickoff planning meeting


Submit RT slides for kickoff ahead of the kickoff meeting


Review relevant templates and resources: progress update template, deliverable guidelines, data management plan, and a sample presentation

RT Leaders

Discuss and review collaborative space ahead of kickoff meeting


Create collaborative space 30 days before the kickoff


Post-kickoff Activity

Kickoff deliverable: schedule recurring monthly meetings with the RT

RT Leaders

Attend follow-up meeting (after kickoff meeting) with the AD and Research Coordinator to align on schedule and progress updates
Agenda: review the guidelines for deliverables, templates for progress updates, and team milestones; team leaders are expected to share the proposed schedule including face-to-face meetings and recurring calls; develop a mutually agreeable schedule for progress updates.

RT Leaders

Follow-up meeting deliverable: schedule progress update calls right after kickoff. Send meeting invites and include all members of the FSC (or just sponsors – need to align with the FSC).

RT Leaders

*RT leaders include investigators, chair, and vice-chair.
The research team should use its kickoff meeting to align on project objectives, scope, expected methodology, and deliverables. Table 3 shows an agenda template for an online kickoff meeting with two sessions of (two hours each) – i.e., the "standard" online kickoff format.
Table 3. Agenda for a Two-session Research Team Online Kickoff Meeting

Agenda item

Time (CDT)



Session 1

2 hours


5 min.

CII and RT Leadership

Safety moment

5 min.

RT Leadership

Introductions team-building activity (Mural)

40 min.

Team Leaders (CII supports a Mural board)


5 min.

CII and project background and expectations

45 min.


Introduction to the project charter

20 min.

RT Leadership

Assignment: read project charter/proposal

Session 2

2 Hours

Introductions (to any new member who missed the first session)

5 min.

Team Leadership (CII supports Mural)

Brainstorming activity:
Starting with the end in mind – problems and expected outcomes

60 min.

Team Leadership (CII supports Mural)


5 min.

Review proposal
Connecting to the brainstorming session outcomes where possible

30 min.

Team Leadership (CII supports Mural)

Logistics and Recurring Meetings
Use pre-determined options for meetings and quick online survey

25 min.

RT Leadership

Next steps and +/Δ

10 min.

RT Leadership

During the kickoff 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 any sponsoring committees.

Research Execution

This section addresses the overall execution of the project by the research team, including guidelines for team meetings, research methodology including validation, and data practices.

Research Team Meetings

Team meetings are critical to organize and deliver CII research. CII's goal is to have an engaged group of industry members meet as a team through all phases of the project. The academics must work with the team's Chair and Vice-chair to plan and conduct team meetings. Good planning should optimize the valuable time that the industry members contribute by attending these meetings. In CII research projects, academics should not work disconnected from the industry team members, and team meetings are the touch points that allow the academics to engage the industry members.
Research team meetings can be either virtual or F2F, but there is strong anecdotal evidence of the relative benefits of F2F meetings, including stronger team building and increased member engagement. Each meeting lasts a full day or a day and a half, and during it team members collaborate to advance the project.
Some CII research teams have adopted online/hybrid meetings. The format of online meetings can be adapted depending on the objectives. For instance, a meeting may become a working session to be performed in subgroups, or a session can be canceled during summertime when team members may be unavailable.
Although each team develops i ts own strategies and tools for online meetings, we provide a few good practices below.

Best Practices for Online Meetings

Online meeting engagement is improved when you include working sessions. Teams have reported success when they formed subgroups to perform distinct tasks during the meeting.

Several RTs have successfully adopted Mural or similar tools to organize working sessions in online and hybrid meetings.

Teams have reported increased levels of engagement when a clear plan outlining the objectives of each meeting is shared upfront early in the process (kickoff) and revisited periodically. This plan helps team members understand why their presence is important in the meeting.
Include a safety moment every meeting.
Allow members to present their organizations (in a way consistent with CII's guidelines for meetings).

Meeting Cadence and Attendance
The RT leadership should set the pace of F2F meetings according to specific project needs. For instance, more F2F meetings may occur early in the process to support team building, scope and methodology definition, and data collection. Fewer meetings may be necessary toward the end of the project, when the team is focusing on writing its report and preparing the presentation. Note that research team F2F meetings beyond the kickoff meeting will be hosted by team members.
CII guidelines for teams are to schedule recurring two-hour sessions every other week and to maintain at least one touch point (online or F2F) every month.
As of spring 2023, our forecast is that teams will continue to rely heavily on online meetings while creating opportunities for hybrid and F2F meetings. We expect two or three F2F meetings per calendar year.
When conducting meetings, whether online or F2F, team leaders must remember to keep track of attendance and submit attendance updates regularly to CII.

Progress Updates

CII schedules progress updates as well as ad-hoc calls with research teams to monitor project progress. The primary focus of each update is to capture progress in terms of methodology, but logistics issues like staffing, attendance, and schedule should also be addressed.
Team leadership (i.e., Chair, Vice-chair, and PIs) is expected to attend these calls along with CII staff and any sponsoring committee representatives.
The team should prepare slides to support the scheduled progress updates and submit these slides to the Program Coordinator before the call. If a team is sponsored by a committee other than the Funded Studies Committee, the leadership of the sponsoring committee should be invited to updates. 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 (i.e., presentation development or report writing and review). The team should also revisit and update its project methodology table during each update (see the "Guidelines for Research Methodology" section above for an example).
Figure 6 summarizes the expectations for progress updates for a typical two-year CII research project. These milestones should be adjusted for other types of projects.

Update 1
focuses on alignment and scope refinement

Update 2
focuses on methodology and revisits the methodology summary table

Focus on data collection and analysis

Focus on preliminary results and expected outcomes

Focus on preliminary results and expected outcomes

Update: Report outline, results and outcomes

Rehearsals replace updates

Presentation and report review

Figure 6. Progress Updates for a Standard Two-year Project

Progress Update Deliverables

The progress update deliverables consist of a slide presentation that uses the provided PowerPoint template and participation in a progress review conference call.
Progress updates typically consist of two parts:

  1. Research Approach and Results, at a minimum, will address the following:
  • Research objective(s) research questions
  • Preliminary and final results
  • Expected outcomes and their value
  • Implementation guidance and resources
  • Research methodology (including the methodology summary table)
  • Research validation (described as the validation table included in the template)
  • 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
  1. The Logistics section of the update will present the following:
  • Current project schedule
  • Research team attendance and engagement, including any request for additional members or notes on members that stopped engaging in team meetings

Tables 6 and 7 describe items to consider during progress updates, sorted by the timing for reporting.
Table 6. Progress Updates – Key Points for Research Methodology and Outcomes

Progress Update Section


Research Questions and Objectives

Review questions and objectives

Research Scope

Clear definition of relevant areas included and excluded from the research

Research Results

Clear and simple description of key findings, clearly connecting each to project objectives

Research Outcomes and Value

Description of the main outcomes described as prototypical tools (e.g., in Excel, checklist, practices, frameworks, etc.)
Clear description of how organizations will use the outcomes and expected or observed benefits

Research Methodology

Succinct and logical methodology described as a methodology table


Description of data – description/identification of planned and collected datasets

Table 6. Progress Update Checklist – Project Logistics

Progress Update Section and Action Items

Responsible Party

Send progress update slides to 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

Collaborative Workspaces and Tools

CII encourages every research team to adopt a virtual space for communications and for file sharing. CII recommends Trello and Microsoft Teams as two good alternatives:

  • Trello supports collaborative planning and file sharing. A good alternative for Trello is Microsoft Planner, part of the Office 365 suite of applications.
  • Microsoft Teams offers a more integrated environment that supports messaging, file sharing via SharePoint, whiteboarding using Microsoft Whiteboard, asynchronous communications (messaging), and online meetings in an integrated environment. CII can create Microsoft Teams spaces but primarily for file sharing: people outside the UT organization cannot be an administrator of the space.

For online and hybrid meetings, CII encourages research teams to use collaborative tools, such as Mural ( or Microsoft Whiteboard. Note that CII will support workshops in Mural for kickoffs if requested by research teams, but team members and academics should use their own accounts afterwards.

Guidelines for Research Methodology

CII research has always been valued by CII members because of its academic rigor. We strive to live up to this expectation and expect academics to drive rigor through their research methodology. To this end, communicating the research methodology becomes a critical issue.
CII's objective is not to wait until the end of the project to receive a detailed explanation of the research methodology. This methodology should be communicated early and throughout the entire process, allowing any questions or concerns to be addressed as early as possible. The methodology is periodically reviewed by academic peers and CII may provide feedback to the team if any concerns are identified.
The point of departure for the research methodology dialogue is the initial proposal – either submitted to the Request for Proposals or developed after a Request for Qualifications. This initial methodology framework is expected to be discussed soon after the kickoff, refined during the initial months of the research, and revisited in every progress update.
The methodology discussion during progress updates should include both a high-level presentation of the methodology and detailed supporting slides. These detailed slides may contain information about survey instruments, tests, models, etc. The high-level overview must be provided as a "methodology summary table," which is a simple way to capture the methodology (see Table 4).
Table 4. Example of a Methodology Summary Table





1. Change and Safety Decision-making Characterization
(Tasks 1 and 2)

Existing literature, online databases, and industry perspectives

Literature review
Internet search
Focus group interviews of RT and CII Safety CBA (SCBA)
Change diaries

Definitions of "change" and "last-minute change"
Types of changes and change descriptors

Existing literature, online databases, and industry perspectives

Literature review
Internet search
Focus group interviews of RT and CII SCBA

Practices, competencies, and skills needed in the presence of change

Existing literature, online databases, and industry perspectives
Safety incident cases

Literature review
Internet search
Focus group interviews of RT and CII SCBA
Review of case studies

Opportunities for technology use
Situational awareness for change decision-making

2. Technology Identification and Mapping
Technologies for preventing serious injuries and fatalities (SIFs) related to last-minute changes
(Tasks 3, 4, and 5)

Existing literature, online databases, and industry perspectives
Safety incident cases

Literature review
Internet search
Focus group interviews of RT and CII SCBA
Review of case studies

Detailed descriptions of available technologies
Mapping of the technologies to:
Practices, competencies, skills
Situational awareness

Existing literature, online databases, and industry perspectives

Literature review
Internet search
Focus group interviews of RT and CII SCBA

Factors that affect technology adoption
Processes for adoption decision-making

Results of Tasks 1 – 4

RT review and analysis of Task 1 – 4 outputs

Promising technologies for preventing SIFs due to last-minute change

Guidelines for Research Validation

While validation is a challenging step in the research process, teams are expected to conduct rigorous validation of the research results. Exceptions to this rule must be discussed with CII during 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 5, which is also included in the progress update template, illustrates a few examples of validation approaches observed in past CII projects.
Table 5. Validation Table with Examples


Types of Validation

No Validation


Few cases


Broad Scope
(all project phases, action by all stakeholders, roadmaps)
↑ ↓
Narrow Scope
(one phase, action by few stakeholders, simple tool)

Definitions of change and last-minute change
Identification of types of change

Available technologies
Develop technology adoption protocol
Develop technology guidance document

Technology adoption protocol evaluation

Promising technologies identification
Change analysis of injury/fatality cases

Practices, competencies, and skills needed

Mapping of technologies
Pilot test promising technologies

Promising technologies field implementation

Color Legend

Not Acceptable



Teams should use Table 5 to plot how their projects will communicate the type of validation(s) planned for different outcomes/results of the project. 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 these data.

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 section below for a link to the template).
If a team plans to use opinion 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 the 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 only 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.
  • Preferably, 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.
  • However, any research findings that still 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 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.

CII expects any data generated by its RT to be submitted to CII at project close-out, including the following examples:

  • An updated version of the data summary table (as provided during progress updates)
  • Data in Excel or another database format approved by CII. Data should be provided through a 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

Projects collecting quantitative project data (i.e., regarding project cost, schedule, etc.) should align with the data fields used in CII's Data Warehouse. This practice will allow data collected by research teams to be integrated into the Warehouse. Data fields can be found in the Benchmarking Associates training materials: integration toolkit, training slides, and session recording.

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 permitted 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

At the completion of the research project, the PI may keep a copy of the dataset with the confidential company, project, and respondent identifiers removed to support future academic research and publication needs. CII asks academics to submit derivative works for comments prior to 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.

Guidelines for Implementation Resources

An implementation resource (IR) can be produced to help end users implement some facet of a research team's research results. The target audience for an implementation resource is the project manager or other field implementers of practices and processes.
In the CII world, the terms "Implementation Resource" and "IR" are often synonymous with "Tool," because IRs typically take the following forms:

  • a self-assessment instrument (e.g., form, checklist, or questionnaire)
  • a document describing a best practice, either current or proposed
  • a proof-of-concept tool for executing a best practice, or a portion of a best practice

The goal is to produce what is most helpful to member organizations in their implementation of the research team's findings.
In general, when a team produces an implementation resource that includes any sort of user tool, it should be validated for usefulness and accuracy through trial use by CII member organizations or by other methods.

Proof-of-concept Tools

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, a team may develop a simple prototypical tool in Excel or Acrobat file to translate the results of its research efforts into a practical application.
These tools create significant added value for CII member organizations and encourage implementation of CII practices, but only if the research team adheres to CII's guidelines about proof-of-concept tools.

Developing Proof-of-concept Tools

When research team members envision a tool for their research, they often dream of building it using the latest technology available without considering the longevity of the tool. Over the decades, many resources were built to make a flashy debut but had to be removed within a few years because they relied on unmanageable software.
CII expects research teams to develop any proof-of-concept tool as Excel or Acrobat files (or similar readily available formats) that can run on a standard off-the-shelf computer with a current operating system and the standard suite of Microsoft Office.
The Deployment Committee will be invited to attend progress updates in order to identify opportunities to drive the adoption of the research results before the end of the project.

Reviewing and Testing Proof-of-concept Tools

In cases where the research team develops a proof-of-concept tool, CII will provide a comprehensive checklist for testing the tool's usability, stress, security, and team acceptance. (You can find this list in Appendix A.)
The Deployment Committee can support the review and testing of these tools.

Labeling Proof-of-concept Tools

CII will describe every new IR with a software tool as a "proof of concept" before it is made available for CII members to download and possibly for non-members to purchase.
Here is the full disclaimer added to the IR product description:
NOTE: This publication's accompanying beta software is a proof of concept and is available for informational purposes only.
By downloading or purchasing this publication, you understand and accept that its accompanying software may stop opening or running properly on future platforms and is not supported or maintained by CII.
Both the publication and its software are protected by applicable copyright restrictions as set forth by CII.
Any party interested in adapting this software is invited to contact CII to discuss licensing.
Maintaining Proof-of-concept Tools
After project completion, research team members, including PIs, are not responsible for maintaining proof-of-concept tools. However, research teams should clearly understand that CII does not have the resources to maintain any published software or website tools – hence to emphasis on tools as Excel or pdf files.

Knowledge Base (KB) Deliverables

Each research team must provide two deliverables that support the dissemination of the research results in the CII Knowledge Base:

  • The KB 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. You can download the template here.
  • The KB tagging checklist is an Excel file that provides the metadata that connect the topic summary to other parts of the KB. You can download the template here.

An example of a topic summary can be found here.

KB Topic Summary

The topic summary gives an overview of the research and its findings. It should be limited to three or four pages and contain the following content:
KB Topic Summary Heading: The heading should provide the team's number and title (e.g., Research Team 283, Industrial Modularization).
Overview and 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 and 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 and 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 7. Examples of Figures that Illustrate Key Findings When reporting the key findings, the team should leverage the graphics from the final
presentation. Figure 8 provides an example of a case where a chart was converted a friendlier figure communicating some research results. Note that
teams are free to explore different types of charts as long as they are easy to read.

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

By contrast, Figure 9 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 9. 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 ones presented 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).


The dissemination phase includes the rehearsals for the final presentation development, and report writing, as well as the development of any other document or resource that communicates the research outcomes.

Online Rehearsals (if applicable) and Presentation

For most research projects, CII organizes online rehearsals with the member(s) presenting for the research team. The online rehearsals help the team to create and develop a narrative that focuses on the value of the research results and entices the audience to adopt 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.
Most research teams should expect two to four online rehearsals, with projects presenting at an Annual Conference having more of these sessions than projects presenting in other events. 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.
Online rehearsals are not included in the initial project schedule defined in the initial proposal. 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, invited industry members, and CII Staff, and all are asked to give feedback. CII may also engage a "presentation coach" who works with the research team in their rehearsals.


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:

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 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.

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. Teams will coordinate with CII regarding submission dates for report drafts and final reports. Some teams presenting at the CII Annual Conference may be able to provide their final reports in time for publication before the conference, while others may 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.
The final report is a 50-page summary of the team's research and its deliverables, written for the industry practitioner (a project management or business unit decision-maker). The final report emphasizes the value and implementation of the results for the CII industry member – it 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. Table 5 provides a recommended report outline.

Table 5. The Elements of a CII Final Report

Final report sections (suggested):

  • Executive summary
  • Introduction (background on problem/opportunity and value of the project outcomes)
    • Project approach (high-level research methodology and overall approach)
    • How to use this document
  • Project outcomes (one or more sections describing the outcomes)
  • Implementation insights (optional)
  • Conclusions (including high-level lessons learned, key take-home learnings, vision for the future)
  • Appendices (detailed methodology, survey instruments, etc.)

The final report must accomplish the following objectives:

  • Clearly communicate the value and benefits of the research results, following a narrative similar to the team's presentation to the annual conference or a board meeting.
  • Explain and illustrate how 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 sections below describe the expectations for the report content.

Addressing Implementation in the Final Report

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). As of Spring 2023, CII is requiring separate and detailed implementation guidance to be provided in an Implementation Resource (see below). The implementation guidance in the final report becomes then a high-level overview that provides insights on:

  • 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.
  • Timing of implementation. 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. Briefly describe which key roles are responsible and accountable for implementing the findings.

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.
In simpler cases, this report may cover all the implementation guidance required for the project deliverables. For more complex tools or practices, a separate Implementation Resource may be necessary. CII will work with team leaders to identify the need for any implementation resources during progress updates.

Addressing Research Methodology in the Final Report

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. However, the principal audience is industry practitioners, so specialized terms may not serve as well as a plain-language description could.
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.


Each team will submit the close-out report no later than the end date of the research team's contract. The close-out report ensures that all deliverables have been submitted and an official final expenditure report is provided to CII. The CII research coordinator will send reminders and follow up with teams in preparation for the project close-out.

Appendix A
CII Product Assessment – Final Report








Executive Summary outlines the key findings of the research

Background, purpose, and objectives of research are clearly described

Original problem statement is described; any changes to original mandate are explained

Research method is clearly described

Research results are well summarized

Conclusions and recommendations are clear

Overall, document is well written, easy to read

Document is not too "academic"

Tables and figures are understandable

Tables and figures add value to the document

Research results as described appear credible

Research findings as described would have significant value within my organization



CII Product Assessment – Tools (checklists, Excel proof-of-concept, etc.)

Research Team Number:

Research Project Title:

Academic Lead:

Team Lead:

Document Title:

Review Date:

Submission No.:








Purpose and use of tool are clearly described

Tool appears to be supported by the underlying research

Tool is straightforward to use

Tables, diagrams, checklists, etc. are clear and understandable

Examples are clearly described and easy to follow

Any restrictions or limitations are described

Minimal or no training would be required to use this tool

This tool would be useful within my organization

I would share this with, or encourage use of this tool by, other organizations

Software tools only:
Evidence of compliance with CII software development guidelines
Yes No

Evidence of testing, verification, and validation has been provided
Yes No



  • No labels