7

My project team and I delivered the design of a 14ha urban infrastructure development in Sydney for a Client. The project was to hand over the development at a Tender level of design, which would be tendered upon by a number contractors. The succesful bidder would then take on the rest of the project as a Design and Construct contract, and complete the works.

As a part of our deliverables, we issued all engineering plans in pdf and AutoCAD dwg, and all design files including the 12d data terrain models and design strings. We have now had a request from the winning contractor to provide the entire 12d '.project' file, which includes all functions, modifiers, appliers and range files. Providing this would save the contractor a significant amount of time, even considering all of the design strings and models which have already been issued.

Our involvement in the project has been completely handed over, and we consider all of our responsibilities departed. There are a number of people in our team who consider it not appropriate to provide the .project file, whilst there are a number of people who don't see it as an issue.

Has anyone run into this issue before, or has anyone got any guidance on whether it should be provided? Are there any risks in sending the information? Does anyone have any thought's on where our Client's ownership of the data ends and our Intellectual Property begins?

Chris Mueller
  • 6,386
  • 1
  • 26
  • 54
Louis Russell
  • 121
  • 4
  • Can you expound a bit more on why releasing the entire project file would be an issue? What cost does that incur to your team? Likewise, would releasing the project file improve the likelihood of a complete and successful plan as designed? As designers, your objective is to make sure the final, completed project is as close to what you envisioned as possible. In other words, I'm failing to see any objections to releasing the project file. –  Jun 19 '15 at 01:36
  • I have the same questions as GlenH7. What are the objections of those who object to releasing the project file? – Chris Mueller Jun 19 '15 at 12:07
  • What is a "12d" model? I can translate most of the terms that you used into what I am used to calling them, but that one I don't understand. (I also understand not wanting to release all of your working files, but I'll leave that for an answer.) – hazzey Jun 19 '15 at 12:40
  • @hazzey Looks like a CAD software package. I'll leave off the link, but it's searchable. – Air Jun 19 '15 at 15:28

1 Answers1

8

Before I start, let me disclose that I don't know a lot about the details of infrastructure projects or your file format, but I think the general considerations are fairly universal.

There are a number of considerations when providing your digital model to a contractor, and in my work I have decided to offer them my model in some situations, but not in others. Here are the main factors:

  • Linear Time. By providing a model, you can probably save the project significant linear time by reducing the amount of work the contractor needs to in order to prepare their shop drawings, allowing the work to start and finish sooner. This is probably the most compelling reason to provide the model. It's worth noting that in some industries where file formats and workflows aren't well standardized, sometimes this efficiency can't actually be realized as things have to be re-drawn or re-modeled anyway for the target platform.

  • Risk. If there is a discrepancy between the model and your drawing, there should be language that instructs the contractor to follow the drawing. However, you have no control over how the contractor uses your model, and they may uncover an error in the model that you never noticed or didn't care about because it is never shown in the drawings. Depending on the contract language, these errors could expose you and your employer to additional liability.

  • Proprietary information. By giving the contractor your design as a complete model, rather than just output drawings, you make it much easier for them to copy designs you may have developed over multiple projects and re-appropriate them on other jobs. While a well-written contract will make that clearly illegal, it's very hard to translate that into recovering financial losses. In addition, any custom objects (blocks, toolsets, plug-ins, etc.) you have created for the software may be transmitted. Again, this kind of intellectual property is hard to control once it is out in the world.

  • Costs. Unless someone made a major mistake, the contractor should have bid the job assuming they had to work off of your drawings (the contract documents) and do or redo any ancillary work required to develop their shop drawings and fabricate/build the job. Likewise, your contract was just to produce the drawings, and the model is simply a tool you used. You may have created a model that is good enough for your drawings, but making it good enough to build off of would cost you money. For the added quality expectation, and the added risk, it would not be unreasonable to charge a fee for providing the model. Even if your model is perfect, the contractor may have questions about some part of it, or ask you to convert it to another format, or otherwise have modest requests that mean you need to devote time to the project that you didn't bid on.

By way of example for the discrepancy issues, when making a drawing for a machined part, I might not draw every feature to scale in my model out of laziness. While this is a bad practice, if I override the dimension and the output drawing clearly conveys the correct information, I have met my contract requirement in the design/engineering role. However, if I then provide the model, and the machine shop doesn't check the written dimension, the piece would be fabricated wrong. Each party will feel confident that this is the other party's fault. If I had never provided two redundant sources of information, blame would have been much easier to assign. This is the same reason that traditionally, we don't dimension segments as well as the whole that they add up to. We try to avoid opportunities for information we provide to be internally inconsistent.

It's obviously not directly applicable to your project, but here in the US, the AISC Code of Standard Practice (AISC 303-10) answers contract questions like these for steel projects when they aren't clearly addressed by a specific contract. See section 4.3 for the details, but the general points are:

  • The contractor can only use the model with permission of the engineer, and only for the one job (not to extrapolate to future jobs)
  • The contractor has to acknowledge that the model is not a contract document (with an exception for projects where the original engineering deliverable was a digital model in lieu of drawings) and is superseded by information on the drawings.
  • The contractor is still responsible for verifying all information
  • The contractor has to remove information not relevant to their scope of work.
  • (In the commentary:) The engineer may choose to charge the contractor a fee for use of the model, without selling the intellectual property rights to the contractor.

In the end, the decision is very job specific. On a fast job with a team that has good existing relationships, it may be worth it to provide the model for free as a good will gesture. On very large projects with lots of locked up risk, it might be wise to only provide what you are contracted to. There may exist a middle ground where providing your model is an option, but only for a price.

Ethan48
  • 4,511
  • 16
  • 41
  • 1
    +1. Was writing an answer regarding time and proprietary information but you beat me to the punch with a much more robust answer. – Myles Jun 19 '15 at 13:56
  • 1
    Adding a point that was partially made, but I want to clearly state it. My working models are usually just that; working. They may have a lot of different versions, construction lines, other information, old information, etc. All of this could confuse or mislead anyone else working with the files. It would take time (money) to clean it up, and even then things might get missed and left in. The clearest model is included in the contract documents already. – hazzey Jun 19 '15 at 15:08
  • What kind of modern cad does not update the model on dimension change? – joojaa Jun 21 '15 at 05:59
  • @joojaa pretty much all CAD programs allow you to override a dimension so it shows a number different than is in the model. – Ethan48 Jun 21 '15 at 13:29
  • I know but why not use a cad program that will update the actual dimension when you type in a value. No need to make a dimension override when actually changing dimension and model is less work than overriding the dimension. I mean fine back in 1990 it took an hour to update but today even the full car model takes less than a minute to update. – joojaa Jun 21 '15 at 14:04
  • It's definitely a sloppy practice, but people do it all the time. Maybe you didn't model in the tolerance between two parts, and you compensate by overriding one dimension up .010" so that dependant features don't all move away. Or maybe you set up a bunch of tubular members to be the dame profile, and its hard to change just one since you have to make two groups and change the original sketch. Its easier to just override the callout/BOM. Also, some folks still draft in non parametric software, where moving the feature in the model might require reassosciating a lot of dimensions. – Ethan48 Jun 21 '15 at 15:38
  • 1
    @joojaa Not everything is always drawn to scale. Sometimes you just need a diagram that is close and shows the proper dimensions in the proper places. – hazzey Jul 22 '15 at 01:55