Abstracted Resource

Plan resource management consists of defining and categorizing resources for a particular floorplan in a manner that is most efficient and effective for the “take-off” process. This is opposed to the organization of resources (material, labor or turn-key) into categories intended to manage the purchasing/vendor process. Both methods of organization of resources co-exist in your Homebuilder Product Management system to provide an optimum process for both required management process.

Problem

Legacy Takeoffs

The Takeoff is a key component in the modeling activities and resources required for a particular plan. A Takeoff is NOT the same as an Estimate.

A Takeoff does not include any pricing component, while an estimate will reflect pricing that is project specific, location specific, vendor specific and specific to a point in time.

The Takeoff represents the profiling of the plan design for its activities and resources that will need to be engaged in the construction of a project specific to that plan design.

The Takeoff will assign these Tasks and Resources for a particular plan design independent of any specified vendor or pricing. Tasks represent each step in a construction process (purchase point or schedule point).

Once a series of activities are assigned to a Takeoff, resources (such as labor, material or turnkey) are assigned to the activity with the appropriate quantities. Since the Takeoff is independent of any vendor or pricing, the Takeoff “template” can be used multiple times on different projects (lots) using an entirely different vendor assignment for each project.

A Newer Version of Legacy?

It was a big improvement when we went from a "one off" estimate to templated takeoffs that could generate a Project Estimate. Here the takeoff template is an abstraction of vendor selection and pricing from the Design Takeoff.

Now that the Takeoff only has products/services and quantities, that template can be used over and over again, even when a new project using that template may have different vendors and pricing.

A Newer Version of Legacy?

Takeoffs, or sometimes referred to as the Bill of Materials (BOM), represent an abstracted view of the project, including all labor and materials.

Not Fully Abstracted

The plan takeoff for a specific plan design remains static, and its template used over and over without regard to how a project specific estimate may be determined in the future. Estimates are specific to a particular project at a particular point in time; the plan takeoff transcends any specific project or point in time.

The abstraction of the pricing from the Design Takeoff is a useful capability and is common to many legacy systems, but is encumbered by the fact that the Takeoff requires specific real world products to be assigned as resources to the Takeoff. Should the need arise to change the Resource Specification level of a group of like products, such as windows, then each Design Takeoff will need to be manually adjusted, one resource at a time.

Solution

Abstracted Resource

A New Methodology

When our proprietary estimating technique is employed into a hierarchical ecommerce construction market, utilizing inheritance, project owners and builders will see the projected actual costs of a proposed construction project both instantaneous and dynamically.

And those projected costs are not based on some generalized amount based on some market study, but real costs from real vendor pricing, with the ability to dynamically change specification levels and vendor assignments as a one click exercise. Even complex requirements such as building code requirements and sales tax issues are automatically taken into account and accurately reflected into a proposed project’s actual costs.

Absolute Properties versus Discretionary Properties

Our proprietary technique takes the abstraction of pricing from the Resources (products, etc.) one step further, by separating absolute properties, such as size dimensions, from discretionary properties. The discretionary properties of the resource (products, etc.) are how a Resource derives its Resource Specification level.

Resource Abstraction

Each Product has one and only one, “Object Resource” for which it is associated. A Product represents the intersection of an “Resource Object” and a “Resource Specification” as represented in the diagram below. Thus, a viable product that is applied to a project based on the parameters of both the “Resource Object” and the “Resource Specification”.

Multiple Resource Associations

Although each Product has only one “Resource Object”, a Product ” can have multiple “Resource Specification” associations. Although “Resource Specifications” most often reflect a quality level, it can be used to group other discretionary properties when necessary.

Multiple Resource Associations

Abstracted Resource Matrix

The following diagram reflects a matrix of how Resource Objects (rows), represented by various sizes, intersect with Resource Specifications (columns), represented by three grade levels. We can see how the Resource Object can include three different products (same row), all with the same size dimensions but with different qualitative characteristics.

Likewise, there are three different products that exhibit the same qualitative characteristics (same column) but include different sizes. This abstraction of the traditional product into Resource Objects and Resource Specifications will be leveraged into a powerful way to maintain takeoffs as well as a way to rapidly change project estimates.

Resource Coding Protocol

When we look at the resource codes for the “Resource Product”, we can see that it is a concatenation of both the “Resource Object” code and the “Resource Specification” code. Here we use the text color RED to indicate the “Resource Object” component and the text color GREEN to indicate the “Resource Specification” component.

Resource Groups

First we define the Resource Groups which groups products of the same type. In this example we utilize the Windows Group and the resources it may include.

Resource Objects

The Resource Object defines a product’s absolute properties. These Resource Objects represent the elements of a product found in a product catalog that cannot be modified without a change to the fundamental Design Plan. Resource Objects will be predefined within the marketplace platform and thus available to use by the marketplace participants.

Resource Specifications

Next we define the various Resource Specifications. The Resource Specifications group a product’s discretionary properties (typically the grade of a product) that by definition are void of any absolute properties.

Resource Products

And finally, the Resource Products are defined. These resources represent the actual real world products and would not be different than products found in a traditional product catalog.

Resource Object Form

Each product will now need to be associated with the appropriate Resource Object and Resource Specification. Below are the Resource Products associated with each Resource Object. Note the associated Resource Products vary in grade but have the same absolute properties, in this case, a size of 3’0” x 5’0”.

Resource Specification Form

Next we need to associate the appropriate Resource Specification to the Resource Products. Here will we look at the Resource Specification edit form where we can see associated Resource Products that are consistent in their Resource Specifications but vary in their absolute properties.

Resource Product Form

Next we will look at the Resource Product edit form, where both the Resource Object and Resource Specification parameters are set via the drop down combo box.

Abstracted Resource Catalog

Each Product Resource as an abstracted relationship within the Resource Catalog. All elements of a Resource, including the Resource’s “Properties” are abstracted from into a table so that any Resource’s unique schema may be defined declaratively.

Abstracted Takeoff

Abstracted Takeoff Hierarchy

Tasks are added to the Takeoff Tasks List. When complete, all Tasks associated with the building of the structure are assigned to the Project. Now the required Object Resources with the quantities required for this Design Plan are assigned to the Takeoff Tasks that will require these resources. These Object Resources will include abstracted materials, labor, and turnkey bids required for the Project.

The Plan Takeoff only includes Resource Objects with their absolute properties, generic and completely void of any discretionary properties. The discretionary properties are associated with the Resource Specifications and assigned at the time a construction Project requires a Project Estimate, much like the vendor assignment with legacy Takeoffs.

Design Plan List

First we will want to define the various Design Plans. These Design Plans form the basis of developing a Design Takeoff.

Design Takeoff List

In the screen below you see where a Plan Design is assigned to the Design Takeoff List. By having a separate table for the Design Takeoff, it allows for multiple versions of a Design Takeoff for each Design Plan.

Takeoff Tasks (aka Activities)

Takeoff Task List

Next we will define the Takeoff Tasks specific to this Design Plan. In this example, these Tasks include a purchasing event (purchase order) associated with a particular Task Takeoff, in this case “Deliver Windows”.

Takeoff Task Form

When we look at the Takeoff Tasks edit form, we see a dropdown combo box for the assignment of the activity to the Design Takeoff and the assignment of the Resource Specification for that particular activity.

Also note that you see a list of associated Task Resources specific to that Takeoff Task, in this case a quantity of twelve 3’0” x5’0” windows and a quantity of two 5’0” x 5’0” windows. A very important aspect of the Resources associated with the plan takeoff activity is that an abstracted Object Resource is used, versus using the traditional product from a product catalog.

Since no qualitative decisions need to be determined by using Object Resources during the takeoff phase, significant productivity gains are realized versus traditional estimating systems on the market currently. This estimating technique is the fundamental component of our patent pending design and is leveraged in many ways throughout the entire platform.

Takeoff Resource Object List

Now that the window Takeoff is complete, we can see a list of the Object Resources associated with the “Deliver Windows” Task.

Takeoff Resource Object Form

Finally, we see the Takeoff Resource Object edit form, used to define the Resource Objects associated with the Design Takeoff Task for this Design Takeoff. Again, note that only an Resource Object is used without any qualitative elements associated with a traditional product found in a product catalog.

Project Estimate List

Next we will see the Project Estimate for the “Deliver Windows” activity. This Project Estimate is the byproduct of the Design Takeoff and the particular “Resource Specifications” assigned. No product resources were selected to determine the project estimate.

Dynamic Estimate

Dynamic Estimating Technique

Our estimating technique addresses the need to make Resource Specification level changes across the plan takeoff, or a group of plan takeoffs, without the need to replace resources one at a time.

This one-click ability of our estimating technique to make on-the-fly specification changes can play a valuable role in quickly optimizing a Project’s construction costs by using what-if adjustments until a suitable cost for the project is obtained.

Although we are only reflecting one Project Task, “Deliver Windows” in this example, a complete estimate would include many Project Tasks; with as little as one Resource to as many as thirty to forty Resources for a given Project Task.

Thus the need to make specification grade changes using traditional takeoff/estimating approaches requires a line by line adjustment of every resource when only real world products are used from a conventional product catalog. This approach becomes quite burdensome and error prone when compared to our patent pending estimating technique as represented here.

Dynamic Estimating Technique (View 1)

Our estimating technique addresses the need to make Resource Specification level changes across the plan takeoff, or a group of plan takeoffs, without the need to replace resources one at a time.

Here we see how the actual real-world products are derived from the Object Resource Takeoff and the Resource Specifications that was assigned to the “Deliver Windows” Task for this Design Takeoff. We can now see specific pricing and extended amounts associated with this Project Estimate.

Dynamic Estimating Technique (View 2)

One click assignment of the Resource Specification are then used to modify the specification grade of products across an entire project so that price comparisons can be made. On the following screen we will see the same Project Estimate for the “Deliver Windows” Task, but with an upgraded Resource Specification selected.

Dynamic Estimating Technique (View 3)

The following screen shows the same Project Estimate for the “Deliver Windows” Task, but with the Resource Specification downgraded using a one click change to the Resource Specification.