Is your project history database “bloated with no accountability” or “streamlined with a librarian?”
“Things that get used don’t get dusty.”
The way forward is simple. But it requires discipline.
Most architecture and engineering firms have some sort of project history database. In fact, they usually have more than one. Project history can be found in enterprise systems like Deltek Vision, custom FileMaker or Access databases, Excel spreadsheets and Word documents, and folders of InDesign templates.
An effective project history database should help your firm to answer “the 5 Ws and an H” – who, what, where, when, why, and how – of your firm’s experience.
Here are a few examples of questions a project history database should be able to answer:
“How many LEED Certified buildings has our firm built?” “Who was the project manager on the Pacific Tech University Lab Remodel?” “What projects have we built for public universities in Washington state in the last 5 years?”
The majority of the project history databases I’ve seen don’t get used. They don’t get used because they are either incomplete or inaccurate or both. The reason for the poor quality of information is that the databases have too many fields and nobody assigned to maintain them.
Because there are no initial costs to creating fields (and because the technology makes it so easy) folks tends to create fields to hold the answers to any question they might ever want to ask without concern for the long-term costs of usability and maintenance.
Here’s what I think you should do to develop an effective project history database:
- Create one source of truth by consolidating project history from multiple locations into one database.
- Keep your project history database simple by prioritizing fields which actually get used.
- Assign a librarian to each field you want maintained. You may well have different librarians for different types of fields. (For example, QA/QC tracking, project roles and responsibilities, location of the record copy of the half-size set, and project descriptions might be maintained by four separate librarians.)
Going forward, you should only add fields into your project history database when you have a clear “use case” for how each field will get leveraged and assign a librarian to maintain it.
I confess to having built a couple overly ambitious project history databases in the past. (I’m reformed now.) We review several project history databases a month through our consulting work. I’ve seen enough examples of the “bloated with no accountability” variety of project history databases to advocate a “streamlined with a librarian” approach to our customers.
I’m currently designing Knowledge Architecture’s internal project history database. I’ll be the biggest user of our database but also the librarian. (You can bet we’ll have a streamlined design.)
Interested in help cleaning up your project history database?
Drop us an e-mail.