UDFs (User Defined Fields) – The Smiling Assassins

UDFs – The Smiling Assassins

 

Hold the presses, someone’s being critical of User Defined Fields, a cherished and much used feature of Primavera. It can’t be right to call them The Smiling Assassins, can it? Well yes it can, because typically they are not so much “much used” but “over used” and seriously misunderstood too. This article has a Primavera angle to it, but if you are using other planning software and think you’ve dodged a bullet, think again. User data presents the same challenges to other software authors and their solutions are not generally any better.

I’ll begin by explaining what a UDF (User Defined Fields) is. It’s a special field/column on a Primavera table created to record a non-standard attribute. It won’t play any part in scheduling, but it might be helpful for reporting purposes. Despite some categorisation options (eg Number, Text) it’s relatively unconstrained, unlike Codes, which have a set list of possible values. UDF (User Defined Fields) can be defined for Activities, Projects, Resources, etc, but the worst offenders are usually at work in the most densely populated areas – the Activities.

What is it that makes UDF (User Defined Fields) such villains, when they seem so benign? It starts with their design and sorry if this is a little technical, but I’ve tried to keep it simple. An activity is a very neat and efficiently designed data item, last time I counted there were at least 209 fixed columns (depending on version), but because they are fixed they all reside on one row in the database and that means they can be fetched with a single read. UDF (User Defined Fields) are not fixed items and they are held in separate tables with complex links back to the original. Fetching just one UDF (User Defined Fields) back to the application actually requires more database activity than the whole of its parent Activity data. A good Database Management System such as Oracle will make effective use of buffering to minimise the impact, but UDF (User Defined Fields) usually come mob handed and can be overwhelming. In case you are wondering, their impact is even more dramatic when you are adding new data and buffering cannot help.

Now you know that UDF (User Defined Fields) are hard work made worse by weight of numbers, you’ll probably have an inkling why I think they may be bad. I gather from my medical friends that many poisons are actually beneficial in small doses and this is a useful analogy. A small dose of UDF (User Defined Fields), administered by a competent project controls manager will be beneficial, but larger doses, especially self-prescribed and unmonitored, will cause serious harm to your Primavera environment. Your system could well be running at a fraction of its optimum performance and you’ve been blaming your network or the database administrator.

Count your UDF (User Defined Fields), all of them, and then see if you can find anyone in your planning team who can tell you immediately what purpose each serves. I doubt you’ll succeed, sincere congratulations if you do, and then remember that each of these smiling assassins is killing your application.

Do you want to know for sure how bad your Primavera environment is? Do you want the truth? Can you handle the truth? Project Pilots can get to the root of the problem, identify just how bad it is and help you frame the necessary improvements. We’ve previously examined many UDF (User Defined Fields) and probably understand these and other smiling assassins (oh yes, there are other dangers), like no one else. Email enquiries@projectpilots.net for further information or call 01707 827925 for further information.

Comments are closed