Project management software or why filing is for losers

This is an article from the Architecture Australia archives and may use outdated formatting

Anthony McPhee outlines the issues and assesses the programmes available for managing projects.

Project management is what architects do. Sure, they design stuff, but that stuff has to be managed. And everything designed – whether a hot tub canopy or satellite city – is a project. They all require communication with others, drawings issued, invoices sent, meetings held.

In a nutshell, project management is, firstly, about arranging what happens when, and, secondly, some method of finding this information at a later date. The first part is achieved by structuring the documents themselves. For example, making sure the date, and who it is to, appears somewhere on correspondence and transmittals. But why the second part? Why do you need to find stuff that has long been and gone? The obvious answer is to help recall what happened in the past. You can try and store it in your head, but human memory is unreliable (the brain doesn’t actually store data; it recreates it on the fly). And why would you want to clog your brain with such mundane information? As an architect shouldn’t you be using your mind for weightier concerns? Like “How am I going to meet my next Subaru payment?” or “Should the glass be light grey, mid-light grey or medium-light grey?”
›› But why do you need to know what happened in the past? Well, it is useful when a client accuses you of not meeting the programme, or you want proof that a consultant hasn’t met the programme. But the real reason is the LAW. As every architect knows, there are many more lawyers in the sea than architects. And they are circling, waiting for prey. Architects don’t earn that much, but indemnity insurance equates to assured money. Architects are not just fair game, but a game of choice. The bottom line is architects must have good project management practices so they can not only survive a shark attack, but retain as many limbs as possible.

The method traditionally used to ensure old stuff can be found is called filing. This is done by tacking on an extra system to the documents created. The Dewey Decimal system for libraries is one, ISBN is another. Your office probably has filing codes. Filing is a very ancient tradition – it is believed that the first writing, symbols pressed into a clay tag, was for filing purposes. To file something with some chance of finding it again you need to do two things: mark it with a filing code, then store it within a container sorted by that filing code. You may have noticed both of these tasks have nothing to do with architecture.

And, I confess, I HATE FILING. Not just because it is boring, repetitive and unappreciated. I’m not very good at it. Give me the same document on different days and it is likely I will file it differently. The only reason I have actually ever done filing is that there is something I hate even more – not being able to find something. Add unproductive and frustrating to the list of why I hate filing above. I know I’m not alone – go into most architects’ offices and you will see the piles of paper and drawings lying around.

Of course, for directors and senior staff in large practices it is not such a big deal – they have staff for filing. But does it get done properly? Who checks? How do you make them do it? Are you going to sack valuable architectural staff because they don’t file? It is essentially a lose–lose situation. Either your staff (or you) are wasting time that could be spent on architecture, or you are exposed if you ever get involved in a shark attack.

Maybe there is another way. What if the act of creating a document also filed it? What if you could find documents not just by their filing codes, but also by other, more relevant information – like person sent to, company sent to, subject, and even words or phrases within the message?

What if you never had to file again?

Younger folk will be familiar with what I am suggesting. They know computer software is good at being accurate when doing repetitive simple tasks. They don’t file, because they can Google. FILING IS FOR LOSERS.

I’m talking about a paradigm shift, not just a new method to use on traditional processes. You can use computers to achieve tasks within a paper-based system, but what is the point? Why use MS Word to type up a document that you then print out and put through a fax machine? All you have achieved is to make it neat. Handwriting straight onto a blank fax form is much quicker and more efficient. Equally, why create a document in Word, and then attach it to an email? It is quicker to just type the message into the email itself. After all, you still have to file it. Does it make any difference if it is a print-out of an email or a word document?

In fact, many offices use email, usually via Microsoft Outlook, as their correspondence system. But email is BAD, email is EVIL. Email was never designed as a business process. It was a messaging system used by people at home, who then started using it at work. It is essentially free (excellent business case), so no-one objected. And no-one investigated if it was really such a good idea. Email is a bad idea because:

  • Email is insecure, so insecure that spam filtering and anti-virus software is now mandatory.
  • It is person-based rather than organization-based. Valuable business messages are locked up in individuals’ email boxes rather than in a shared resource. If an email was only sent to one person, and that person is not in the office, how does someone else get to it? (A common problem when email is sent to directors.) When somebody leaves, how do you get to all the emails in their inbox?
  • Email generates immense amounts of data, a large proportion of it being duplicate data – messages CCd to multiple people in the office, messages with attachments CCd to multiple people.
  • Because of the amount of data email uses, most businesses put size limits on email – 5MB is common. For architects this is a real problem as large files, or large numbers of files, can’t be sent as email attachments.
  • Email is unstructured. Sure, you can create folders to organize emails, but you need to move emails into various folders manually.
    This is called filing. (I defy anyone to get email filtering working consistently, particularly in Outlook.)
  • Email mixes business communication with other types. Messaging within the office, “Paris is at the hairdressers and won’t be in till 12:00”, lunch arrangements and other conversations with colleagues, within and outside the office, are all mixed in with fee agreements, client briefing and transmittals.
›› Basically, email creates a huge, disparate, amorphous mess. And what happens when the sharks start circling? There is a legal process called “Discovery”, where each side is required to produce all documents they possess relevant to the case before the court. If your office system is email, someone senior has to trawl through the mess of emails in everyone’s mailbox, including people who have left. And what about the emails in your archived inbox – the ones from colleagues answering your queries about the moral character of the client bringing the action? Sent before the job even started. And they answered honestly. You might think they are not relevant, but be assured the client’s counsel will have a different view.

So not all software is equally up to the job of project management. What makes a proper project management system? Basically, a project management system should allow you to generate messages, store documents and be able to search for both. You would expect such a system to:

  • Be organization-based. All project data is available to everyone within your office (unless specifically marked as restricted or confidential).
  • Be project-centric. Data can be divided into projects, not just clients or invoices.
  • Store and manage contact information.
  • Create messages and send them.
  • Accept messages and store them with minimal user input.
  • Store generated documents and manage revisions.
  • Create transmittals and issue documents as a single process.
  • Store received documents with minimal user input and manage revisions.
  • Search for anything.
  • Produce reports.
›› Currently available project management software can be divided into two categories: project collaboration and office management. Project collaboration software is designed to allow the different players involved in a building project to communicate and share information. It is invariably web-based, hosted by a remote server that is accessed by everyone via the internet using any web browser software.

Office management software manages all the projects within an office. These commonly include tasks beyond collaborative software, like resource management (for example, time sheets), client management, invoice management and contract administration. They usually live on the office computer system and require specialized software to run on.

In the context of the current discussion, the practical difference between the two is that with project collaboration software you don’t need to file incoming messages or documents as the person issuing them does it for you (they log on and add the documents to the system themselves). With office management software, incoming messages and documents need to be put into the system. Yes, FILED! However, they generally have tricks to make this as painless as possible. For example, you may only have to identify the appropriate project to file a message or document.

Unfortunately, the two categories as they exist now are mutually exclusive. Project collaboration software is cumbersome (and often expensive) to use for every project within an office. Office management software doesn’t allow the inclusion of parties outside of the office. So, for example, your consultants can’t directly upload their drawings into your register. Worse still, neither can talk to the other. So if you are using project collaboration software for a large project in your office, the data put on that system won’t exist on your internal system, and vice versa. This is a very real problem faced by many architectural practices today. Architects are often forced to use a project collaboration system by clients or contractors – sometimes one owned by the contractor or client. This means that it is not uncommon for an office to be using several different systems at the same time for different projects. This situation is no worse than paper- (or email-) based systems, which by their nature are incompatible with project management software. So the advantages of digital data-driven systems are still valid.

The solution is to accept that project data may be stored in different digital systems within the office. If managed it is workable. The first thing is to ensure that all project data, or all data from a stage of a project, is completely within one system. This situation is not really new – it is similar to a client insisting that their document numbering, CAD file naming and layer naming be used for their project. It is a problem that is not going to go away until there are common standards, which may happen one day, but who knows? At least work is currently being done on this both in Australia and overseas (for example, aecXML).

So don’t let the fact that you are currently using various project collaboration systems stop you from implementing an office-wide solution. To recap the benefits of project management software:

  • Filing is automated and consistently done.
  • Documents can be found quickly.
  • Expensive staff are better utilized, and you require fewer lower-level staff.
  • You and your office can spend more time on architecture.

Antony McPhee was a principal at Ashton Raggatt McDougall until the end of last year. He now consults on office management, IT and BIM to architectural practices and is a member of the RAIA National Integrated Practice Taskforce. He can be contacted at


[1] Base your selection of a system on projected future needs. Take advantage of the opportunity to do things differently rather than try and match what you do now.

[2] Look at more than one system.

They are all different and you won’t find one that perfectly fits your needs.

Choose the one you think you can work with best.

[3] Get demonstrations from short-listed systems. Allow sufficient time to thoroughly go through them, at least three hours each.

[4] Avoid customizing the software.

If you do, make sure you are not doing it to mimic paper- or email-based methods.

[5] Pre-plan implementation. Look at what processes you could change in your old system to make the transition easier. Consider moving to “paperless”, where all drawings and documents must be printed to digital format (pdf or dwf), and direct printing to printers and plotters from application software (CAD, MS Office, etc.) is banned. Encourage A3 reduced printing instead of plotting.

Consider using bureaus instead of in-house plotting for large print runs.

[6] Plan implementation. Decide on, and stick to, a method when moving to the new system: a uniform changeover date, or selected projects, or new projects only.

[7] Consider historical data. If you already have a system in place, it is probably a waste of money putting historical data into a new system. If you decide to do it, make sure it is properly resourced or it will take forever!

[8] Make sure you have adequate hardware, including backup and internet connection, to support the system.

[9] Assess and resource how staff will use the system. Make sure you have reliable, fast printers. Consider hardware – for example, twin monitors can reduce the amount of printing.

[10] Allow time for staff to train and get used to the system.

[11] Periodically check that staff are using it correctly.


[1] Costs vary depending on the type of system and its capabilities.

[2] Remotely hosted web-based systems (usually project collaboration systems) tend to charge an ongoing usage fee, based on either project value or the number of users in your office. Office management systems that live in your office are usually fixed cost plus annual support agreement.

[3] As a rough guide, up-front costs are around $10,000 to $20,000 for 20 users. Annual support agreement is about 25 percent of the up-front cost. The range is large because most vendors allow for customization in their price. The experience to date has been that architects demand changes to suit their current practices. One vendor quoted $10,000 for the software, and $10,000 to customize it. If you want to save money, DON’T CUSTOMIZE.

[4] Let’s say a system costs $15,000 to purchase. You have 20 staff; cost per staff is $750. Say the average cost to the office of staff is $50/hour. So, to break even the system would need to save each staff member 15 hours per year, or 20 minutes per week, or four minutes per day. And that is only in the first year. At $3,750 per year for support cost it drops to five minutes per week or one minute per day. Can you afford not to implement project management software?


The architect project management software market in Australia is far from mature, and new players are bound to pop up in the near future. Much of the office management software on offer started out as in-house systems developed in larger architectural practices, and as such they reflect the business practices of these offices. Some are little better than digital versions of paper-based systems. The list below is not exhaustive, and I’ve personally used only the project collaborative software.

The comments are general only and I encourage you to investigate all of them.


Simple and easy to use, but it only has basic mail and document management.

Excellent training, support and help desk. Good if you are new to this type of software, but it lacks sophistication for proper project management, particularly during construction.

Project Centre
Highly configurable system that controls contract forms well (RFIs, etc.), work flow (who can what to whom) and document management (creation of drawing sets). Not as pretty as Aconex, more workmanlike.

Good support and training.

This is the web collaboration tool developed by QA-software, which has provided software to the construction industry for many years. Although fully featured due to their depth of experience, some of its processes are unnecessarily cumbersome and appear to be based on traditional paper-based processes.


The Silent Partner
Although currently primarily used for project collaboration, this system is actually designed to also provide inhouse project and office management.

It is a fully featured system similar in functionality to Project Centre.

It attempts to bridge the gap between disparate systems by incorporating export and import functions, using ISO standards. Unfortunately this is of little use until other vendors also incorporate this feature. It can also export to bookkeeping software like MYOB and QuickBooks.


Architects Office
Developed from a system used by a large practice. Generates paper forms but doesn’t store digital documents.

Its claim that it “replaces a minefield of word templates and excel spreadsheets” suggests its focus is on automating paper-based methods.

Fenwick Software – Everyminute everyminute.html
Generic professional services management software. Only does resource management and invoicing.

Doesn’t manage correspondence or documents.

Fully featured office management system. Built on proprietary software (Filemaker Pro), so requires purchase of this software. Filemaker has an Apple version, so may be worth considering if your office only uses Apple computers (all web-based systems will work on Apple computers as all they require is an internet browser).

By the makers of Teambinder, so same comments apply. Correspondence, document management and time sheets are all separate modules.

Professional services management software only. Can export data to bookkeeping software like MYOB and QuickBooks. Doesn’t manage documents.



Published online: 1 May 2007


Architecture Australia, May 2007

More archive

See all
August issue of LAA out now August issue of LAA out now

A preview of the August 2019 issue of Landscape Architecture Australia.

Houses 124. Cover project: Garden Room House by Clare Cousins Architects. Houses 124 preview

Introduction to Houses 124.

Architecture Australia September/October 2018. AA September/October 2018 preview

Local and global recognition: An introduction to the September/October 2018 issue of Architecture Australia.

The August 2018 issue of Landscape Architecture Australia. August issue of LAA out now

A preview of the August 2018 issue of Landscape Architecture Australia.

Most read

Latest on site