There are multiple reasons to manage binder sizes such as, but not limited to, binder transfer rates between the server and workstations (local and remotely connected from the field), network load, and storage space. The two most common contributors to the growth of binders is 1) the types of files stored in binders and 2) the number of files stored in binders. Documentation requirements may prevent users from addressing #2 but #1 should be a concern of all users, Engagement administrators, and system administrators.
By "type" of files I'm referring to the file type and the charactaristics of those files. For example, a PDF generated by convertion from a Word file may not take much space but, in contrast, a full-color scanned PDF may consume large amouts of disk space. This plays a larger part of binder size when the Perm File is large or is housed within the workpaper binder (i.e. Perm File and workpapers are in one binder; the firm I work for chose this setup).
Getting the file size data isn't as easy as one would like. CCH created the ReportBuilder application which basically performs queries on the Engagement database. It has several standard queries that return a lot of useful information. However, none of the queries returns binder size. As far as I can tell, the binder size is not stored in the Engagement database because its solely the size of a directory on the server or workstation. This is the problem: How can I run a query from ReportBuilder to get a list of the binders on the server(s) and match it to the directory size? The solution I use is somewhat manual.
Due to the nature of our clients and the firm's choice to combine the Perm File and workpapers in one binder, I've set the target max binder size at 100 mb. Some binders are above that and other are below. One of our biggest audits tops 1 gb, mostly because of the size of the Perm File.
Armed with the list of binder sizes and the target max size, I filter out the binders that have been finalized (I don't want to mess around with documenation past the regulatory deadline for assembly). I'll then identify a few candidates for reduction and view the directory details on a workstation (because the server has everything zipped up in .szp files). Most of the time it ends up that the PDF files are way to big for the number of pages within the document so I have to resave/compress the file to reduce the file to a better size.
If anyone else has suggestions, please feel free to share by leaving a comment. I think we'd all love to hear others experiences and solutions.
