1. Home
  2. General functionalities
  3. Request for change (RFC)

Request for change (RFC)

Ideally, requirements do not change during a project, but every project manager knows that change cannot be avoided entirely. Changes may come from new insights, budget changes, feedback from contractors, regulatory changes and more. This does not have to be a problem, as long as change happens in a controlled way.

BriefBuilder’s RFC (request for change) functionality helps you with this. It allows you to systematically log, assess, and accept or reject change requests in relation to requirements.

This feature is typically used in design and engineering processes, allowing project participants (e.g. contractors or architects) to request changes in the project brief. It is also possible to use the RFC feature for contract management (e.g. Design & Build contracts), review processes (e.g. by internal stakeholders or external experts) and/or managing RFCs during tender procedures.

To make different uses possible, the RFC feature is flexible in its set-up. You can define your own RFC statuses (e.g. open, closed, …) and your own RFC properties (e.g. priority, impact, …) via the settings menu.

Please note: BriefBuilder’s RFC feature focuses on requirements. RFCs concerning other matters (e.g. timelines, budgets or BIM models) can best be captured in a CDE system (e.g. Dalux Box or BIM 360), which can be linked to BriefBuilder’s RFC feature by means of cross-links.

Example of an RFC process

Below is an example of how the RFC is typically used in the interaction between a construction client and a design team. But, as said, the set-up is flexible and the feature can thus be used in different ways.

  • When the project brief is ready, all edit rights are withdrawn so that nobody can make unauthorized changes.
  • Members of the design team get permission to create RFCs.
  • Members of the client team get permission to assess RFCs.
  • When the design team wants to have a requirement changed, they create an RFC (with a status open).
  • The client’s requirements manager looks in the RFC table for RFCs with the status open that are awaiting an assessment.
  • If so, the requirements manager may assign these RFCs to members of the client team, depending on what type of expertise is required.
  • Those assignees then assess the proposed change’s impact on the project (e.g. on its budget and timeline).
  • Based on their assessment, they add an assessment outcome (accepted/rejected) for each RFC.
  • The design team then checks in the RFC table whether their requests have been responded to, and they review the assessment’s outcome.
  • If the client’s assessment is clear, and properly implemented (in case of acceptance), project participants put the RFC’s status on closed.
  • If the client’s assessment raises questions, or if an accepted RFC has not been properly implemented, they leave the RFC’s status on open. In that case, they can add a comment to the RFC to discuss the RFC with the client, which should ultimately lead to the closing of the RFC.

As said, the above is just an example. Below, we will explain the practicalities of BriefBuilder’s RFC feature in a more generic sense.

Creating RFCs

There are two ways in which you can create RFCs:

  1. In the RFC table: you first create an RFC and then link it to one or more requirements.
  2. On the detail view of an object: you create an RFC for a specific property.

Both will be explained below:

Creating RFCs in the RFC table

In the RFC table (Navigation menu > RFC > RFC table), you can create an RFC by clicking on the icon that you can find right next to the table’s name.

The newly created RFC then appears at the top of the RFC table. To work with it, you first have to click on it (in the column RFC ID)

You have to click on the RFC’s ID , or the arrow-icon, to open it.

In the RFC’s detail view, you can then you link the RFC to one or more requirements by clicking on the button Link requirements to this RFC (or the icon). When doing so, you will get to a selection menu which you can use to find the relevant requirements.

Please note: using the selection menu for requirements works best if you have some understanding of the overall model set-up (trees, object types, requirement subjects). You can get this understanding by simply clicking and browsing through the model. You may also want to take a look at our explanation about BriefBuilder’s structure.

And then there is obviously the request itself: what needs to be changed and for what reason? This can be explained in the description field under request.

Creating RFCs on a detail view

You can create an RFC on the detail view of an object (e.g. a space or a system), behind the specific requirement that you would like to have changed.

To do so, you first have to make sure that you see the RFC feature on your screen. This can be done by clicking on the fourth button of the view options in the upper right corner of the object’s detail view.

Click on ‘Show RFC’ (fourth button from the left).

Once you have done that, you will see a small RFC icon () behind each requirement.

About the RFC icon:

– If it is grey, there are no RFCs for a requirement.
– If it is black, there are RFCs, but their status is closed.
– If it features a small red dot, there are ‘unclosed’ RFCs.

By clicking on the RFC icon, you go to the RFC list for that requirement. There, you can create an RFC by clicking on the Create RFC button. The list also shows earlier RFCs and their status (of which you can view the details by clicking on their ID or by clicking on the icon).   

When you click on the Create RFC button, you get to see a screen in which you can fill in the RFC’s details. Most important is to explain what the desired change is. You can use the description field for this purpose.

When writing an RFC:

Be as precise as possible. What is it exactly what you like to have changed in a requirement? A value, a quantity, a unit of measure, a name, a note, …?

Make sure to explain the reasons for the proposed change. Is it related to feasibility or budget? Is there an error or flaw in a requirement? Is it because the requirement is ambiguous?

Think about the format. Do you use full sentences (“We would like to change this into….”), commands (“Change this into … “) or questions (“Is it possible to change this into …)?

If relevant, you can also upload documentation concerning your change request (e.g. a calculation of drawing that explains why a requirement needs to be changed). Depending on how the RFC feature has been set up, it may also be possible to indicate the RFC’s priority, or to add a link to a CDE/document management system.

All the created RFCs come together in the RFC table, where you can easily check whether your RFC has been responded to or not.

Assessing RFCs

When you are responsible for assessing RFCs, you will most often start in the RFC table where you can see if there are any RFCs that are awaiting an assessment. These are the RFCs that do not yet have an outcome in the column Assessment. You can find these by using the filter “empty” in this column.

If you want to find the RFC’s that are explicitly assigned to you, you can use your own name as a filter in the column Person responsible.

You can also use the column Status to look up RFCs that have “open” or “ready for assessment” (or something similar) as a status, depending on what kind of statuses have been defined in the settings menu.

When you have identified the RFC that you want to assess, you can click on the RFC ID, or the icon. When doing so, you will get a pop-up that is divided into two parts. The first part contains the details concerning the request, the second part is where you can add the assessment details.

The assessment details can differ per project, but in any case, you will have to fill in an assessment outcome (e.g. accepted or rejected), and ideally also a Note that explains why you have come to that conclusion.

If you have questions or comments concerning the RFC, you can use the comment function that you can find at the top of the RFC detail view.

Please note: if you prefer to see the RFC in its context (= on the detail view of the object to which the RFC applies) you have to go back to the RFC table and click on the object’s name there.

Closing RFCs

The status of an RFC can be put on closed when there is no further action required. Closed is the end state of an RFC.

You can change the status of an RFC by clicking on the status button in the upper right corner of an RFC.

There are three possible reasons for closing an RFC:

(1) RFC is rejected
It can be that the RFC is rejected, for example because of its impact on the project’s budget. If this assessment is not leading to further questions, the RFC can be put on closed. If there are questions, it best not to close the RFC yet and to use the comment feature to contact the person that has assessed the RFC.

(2) RFC is accepted – and properly implemented
The second possible reason for closing an RFC is that it has been accepted. In that case, however, the recommendation is to first check whether the requested change has been properly implemented.

You can check this by clicking on the RFC, looking in the Requirement field whether there have been any changes. If a change has been implemented, you will see two requirements:

  • the current requirement, and, underneath it,
  • the earlier requirement (the requirement as it was when the RFC was created).
In this example, the current requirement is 2.95 m. The ‘old’ requirement (when the RFC was created) was 2.7 m.

You can compare these two to ensure whether the proposed change has been properly implemented. Please note there may be multiple RFCs for a single requirement, so it can also be that a requirement has changed in relation to another, perhaps more recently created RFC. This can easily be checked. To do so, filter on that requirement in the RFC table, or go find the requirement in question in the model via the search function.

(3) RFC is no longer relevant
It can also be that an RFC is no longer relevant, which is an obvious reason for closing it, or even deleting the entire RFC.  

An RFC may no longer be relevant because

  • the requirement has changed after the RFC was created;
  • the requirement or the object no longer exist;
  • there are newer RFCs that are more relevant.

To check the relevance of an RFC, you can compare the current requirement with the requirement as it was when the RFC was created (as mentioned earlier).

A crucial question in any RFC workflow: who gets to close an RFC?

The permissions in BriefBuilder are such that it is the ‘RFC creators’ who can close an RFC as it is ‘their’ RFC, and not the assessors’.

This may feel strange, however, when the contractor and the construction client are working in the same model, with the latter being responsible for all the model’s content.

In that case, you can decide that it is the person with the Requirements manager role (typically the one responsible for all that happens in the BriefBuilder model) who is responsible for closing issues. He or she is then the ‘RFC manager’.

Commenting on RFCs

Just like elsewhere in BriefBuilder, it is possible to create comments for RFCs, to assign these to particular users, and to answer on comments.

Just like elsewhere in the model, it is possible to create comments for RFCs. These comments are then shown in the comments overview. Furthermore, users can get email notifications when there are comments for them.

This functionality will typically be used for the more informal communication around an RFC. Think of comments like “Can you add some more detail to your RFC?” or “We have changed the wording, please take another look” or “Can we close this issue?”

For a general explanation about how to work with comments see here.

RFC history

To see how an RFC has evolved over time, you can click on the button (‘show object history’) in the upper right corner.

When doing so, you’ll see the RFC’s history data concerning its creation, status and the different property values, indicating who has done what and when.

The RFC table

All RFCs concerning a project can be found in the RFC table (which can be accessed by clicking on RFC Table in the navigation bar).

The table features several filtering and sorting options that you can use to find the RFCs that you are looking for. See below for some examples.

When your role is to assess RFCs, and you want to find the RFCs that you still need to assess, you should:

  • Apply the filter option ‘open’ in the column Status
  • Apply the filter option with your own name in the column Person responsible
  • And then apply the filter ‘empty’ in the column Assessment

When you have created one or more RFCs and you are curious whether these have already been assessed, you should:

  • Apply the filter option ‘open’ in the column Status
  • Apply the filter option with your own name in the column Created by
  • And then apply the filter option ‘not empty’ in the column Assessment

All of this depends obviously on how the RFC feature has been set up.

If you want to know more about a particular RFC that you see in the table, you have to click on the RFC’s ID or on the icon at the end of a row.

To find RFCs that concern requirements or objects that have changed or have been removed, you can use the filter changed (the icon) in the RFC table.

Those RFCs are in most—but not all—cases no longer relevant, and thus obvious candidates to be put on ‘closed’.

RFC Dashboard

The RFC information is also available on a dedicated dashboard. Each RFC attribute (status, responsible, outcome etc) is presented there as a pie chart.

RFC dashboard

TIP: clicking on a particular ‘pie’ in the pie chart brings you directly to the relevant part/selection of the RFC table.

RFC settings

In the settings menu, you can adjust properties for both the request and the assessment part of the RFC.

You can find the settings menu at the bottom of the main navigation bar (Settings > RFC > standard properties). Please note that you must have the role requirements manager (or similar) to be able to see and adjust the RFC settings.

In the RFC settings, you will notice that there are a few predefined properties, for both the request and the assessment part of an RDC. You can easily change these and add more properties if needed. See below for some examples.

Tip: when adding new RFC properties, you can choose where to place them. In the column placement you can choose between:

– Full width
– Left side
– Right side

RFC – Request

The standard set-up has two properties that cannot be deleted (although it is possible to rename them):

StatusThis property is used to indicate whether an RFC is open (sometimes also referred to as ‘active’) or closed (the end state of an RFC).  

You can rename these if you wish, but make sure that their meaning remains more or less the same because they both have particular function in the application. The open status is the default status for a new RFC, and the closed status is used to calculate how many RFCs still require some kind of user action. This number shows up in the little red dot behind a requirement.  

You can also add more statuses, e.g. concept or ready for assessment. Remember, however, that it is only users with request permissions who can change an RFC’s status.  
DescriptionThis property is the text field where RFC creators can describe what needs to be changed about a requirement and why.   This property can be renamed, but not deleted.  

Depending on the specific needs and workflow in your project, you can add more properties if you wish to. See below for some examples.

Link to CDEIf there is a CDE system in use in the project (e.g. Dalux or BIM360) where more general RFIs are being administered, you may want to create a dedicated field where you add url/links to particular RFC/RFC documents in that CDE.
PriorityIf there are a lot of RFCs in a project, you may want to have a possibility to prioritize them, with options such as high, medium, and low (to be able to do so, you must choose picklist as input type).  
Responsible personIt can be that you want a second (or even a third) person to review an RFC request before it is official. In that case you have to add properties that have user as input type.  

Please note that it is not possible to enforce a particular workflow in BriefBuilder. For example, the application cannot dictate that an RFC needs to have an approval before it can be assessed.
TypePerhaps you want to differentiate between different types of requests. You can, for example, create picklist values such suggestion for improvement and correction of error.  

Tip: Avoid creating all too many RFC properties because it is likely to make your RFCs too complex!

RFC – Assessment

The standard set-up for assessment consists of three properties:

Person responsibleThis property can be used to assign an RFC to a particular person. It is an optional property, however, that can be deleted if not needed.   You can also add extra properties with user as input type, if you want more persons to be involved in the assessment.  
OutcomeThis is a mandatory property with three default values:

Rejected (the requested change will not be implemented)
Accepted (the requested change is accepted, but not yet implemented)
Implemented (the requested change is accepted and has been implemented)

You can change the names of these statuses and you can add more statuses if you need to.
NoteThis is a mandatory text field that can be used for explaining the reasons for the assessment.

Depending on your needs, you may want to add more properties. For example:

ImpactYou may want to add this property as a kind of assessment categorization, with picklist values like high, medium, and low. Some projects even feature three different properties:  

– Impact on budget
– Impact on timeline
– Impact on functionality. Each with their kinds of values (e.g. high, medium, low)  

RFC permissions

BriefBuilder has a simple set-up for permissions concerning RFCs, which can be managed via the settings menu in your project model, via the button permissions.

In the permissions overview, you can see two columns dedicated to RFCs: RFC request and RFC assessment.

In these columns, you can define, for each role in your project, what the relevant RFC permissions are. You have the following possibilities:

RFC Request

Configureallows users to configure the RFC request set-up via the settings menu, including the possible statuses.
Editallows users to create and edit RFC requests
Commentallows users to make comments to RFCs

RFC Assessment

Configureallows users to configure the RFC assessment set-up via the settings menu, including the possible outcomes.
Editallows users to create and edit RFC assessments

You may notice that there is no comments permission for RFC assessment. This is because the comments are all linked to the RFC request. To allow RFC assessors to respond to the comments of RFC requesters, they should get the Comment permission for RFC requests.

Furthermore, it is important to mention the role of the requirements manager in relation to RFCs. It is the requirements manager that typically sets up the RFC structure. Furthermore, he or she is often the one that manages the entire list of RFCs, e.g. deleting or closing RFCs that are longer relevant.

Requirements manager

With this role you can:

  • Define the RFC settings
  • Create RFCs
  • Edit both the request and the assessment part of RFCs
  • Create and answer comments concerning RFCs
  • Delete RFCs (including RFCs from others)

Please note that all the project participants’ actions concerning an RFC can be traced via the history button of an RFC.

Was this article helpful?

Need Support?
Can't find the answer you're looking for? Don't worry we're here to help!

Leave a Comment