The danger and opportunity of PDTs

You'll need to know what a PDT is before reading this post.

The idea of creating generic sheets containing high levels of detail for specific product types I have previously said is a necessary idea. We need to capture, structure and standardise information if we have any hope of automating how we process that information.

There is a danger frequently skirted around which is failing to accommodate the capabilities of software when developing standards. This situation is created by the entirely understandable principle of not wanting to be software specific, which is a fine (emerging) tradition that we can continue. This doesn't mean that we have to create standards that aren't fit for purpose, and let's be clear, I believe that the PDTs will be fit for purpose. Software behaves in a few general ways that are predictable and can be accommodated for.

The problem

1. Software is a machine

A really hard part of using computer science to solve problems is predicting how the user will use the software and how this compares to what's achievable by computers. Computers can beat the best chess players, because there is an underlying logic there that it can work with. Computers can't understand speech perfectly or recognise birds reliably, because there is a vast array of greys, they need to make sense of something before being able to process it which they find hard. Whereas with the chess example the 'sense' has already been defined by the rules of the game. These rules are discreet and can be expressed mathematically. The thing to take away from this is, to know what PDTs need to do, we need to know that computers can do with them.

2. Requirements are hard to capture

Finding solutions for problems using computer science is hard, and PDTs are no different, it's entirely possible that we will only know what we need them to do once they're developed. But hey, that's why we have version control, so that we can create updated versions. The thing to take away from this is that in order to use PDTs effectively, we need to know what they will be used for.

The solution

Clean inputs

Ensuring that PDSs' are filled out consistently will allow them to be computer processed most effectively. The restriction of inputs into PDSs' may be feasible, or using protected letters e.g. a comma means there are multiple items in this field and therefore this field should be treated as a list. Another example is na. n/a, N/a, N/A, not applicable, not aplicaable etc etc etc. If the inputs are clean and standardised, through whatever methods, then you can rely on a computer to process that information effectively. If not you will get spurious information that will require you to manually process the information to clean the data so that the computer can use it. A real waste of time and money.

Wide consulting

This is already being done in the quarters that I am aware of, but is vital. Every discussion I've had regarding PDTs has ended up with a group of us trying to imagine what stakeholders who aren't present will use them for. Luckily we have representatives from the key stakeholders present at our Landscape Institute BIM working group meetings, so that works very well in capturing those requirements. You need someone present who isn't imagining what something might be used for, but knows. There is no such thing as a construction generalist, so we are required to consult. The danger is that otherwise, the PDT is not fit for purpose. 

Conclusion

PDTs will be fit for purpose, because of the number of intelligent, well informed and experienced individuals involved with them. However, there are pitfalls and anyone could fall into them.